Abhilfe bei Problemen mit ZFS-Dateisystemen

Abhilfe bei Datenproblemen in einem ZFS-Speicherpool

Beispiele für Datenprobleme umfassen:

vorübergehende E/A-Fehler aufgrund eines fehlerhaften Datenträgers bzw. Controllers
Datenbeschädigung auf Datenträgern aufgrund kosmischer Strahlung
Treiberbug, wegen denen Daten falsch transportiert werden
versehentliches Überschreiben von Bereichen auf einem physischen Datenträger durch einen Benutzer

In einigen Fällen treten solche Fehler nur vorübergehend auf, so z. B. bei sporadischen E/A-Fehlern aufgrund eines Controller-Problems. In anderen Fällen ist der Schaden bleibend, wie z. B. bei der Datenbeschädigung auf einem Datenträger. Auch wenn der Schaden bleibend ist, heißt das nicht, dass der Fehler wiederholt auftritt. Beispiel: Wenn Sie versehentlich Bereiche einer Festplatte überschreiben, ist kein Hardwareausfall aufgetreten, und das Datenspeichergerät muss nicht ausgetauscht werden. Genau festzustellen, mit welchem Problem das Datenspeichergerät behaftet ist, stellt keine leichte Aufgabe dar und wird später eingehender behandelt.

Überprüfen der Integrität des ZFS-Dateisystems

Für ZFS gibt es kein Serviceprogramm wie fsck. Dieses Serviceprogramm diente üblicherweise zur Reparatur und Validierung von Dateisystemen.

Reparatur von Dateisystemen

Bei herkömmlichen Dateisystemen ist die Art und Weise des Schreibens von Daten von Natur aus anfällig für unerwartete Ausfälle, die zu Inkonsistenzen im Dateisystem führen. Da herkömmliche Dateisysteme nicht transaktionsorientiert sind, können unreferenzierte Datenblöcke, ungültige Verknüpfungszähler oder andere inkonsistente Dateisystemstrukturen auftreten. Mit der Einführung des so genannten Journaling wurden zwar einige dieser Probleme behoben, es können jedoch neue Probleme auftreten, wenn Transaktionen nicht rückgängig gemacht werden können. Inkonsistente Daten in einer ZFS-Konfiguration können nur bei Hardware-Ausfällen (was durch redundante Pools vermieden werden kann) oder bei Bugs in der ZFS-Software auftreten.

Das Serviceprogramm fsck beseitigt bekannte Probleme, von denen UFS-Dateisysteme betroffen sind. Die meisten Probleme, von denen ZFS-Speicher-Pools betroffen sind, sind auf ausgefallene Hardware oder Stromausfälle zurückzuführen. Viele Probleme können durch redundante Pools vermieden werden. Wenn Ihr Pool durch ausgefallene Hardware oder einen Stromausfall beschädigt wurde, gehen Sie wie unter Reparieren von Schäden am gesamten ZFS-Speicher-Pool beschrieben vor.

Wenn ein Pool nicht redundant ist, besteht immer das Risiko, dass Sie nach einer Beschädigung des Dateisystems nicht mehr auf Ihre Daten zugreifen können.

Validierung von Dateisystemen

Neben der Dateisystemreparatur stellt das Serviceprogramm fsck sicher, dass Daten auf einem Datenträger fehlerfrei sind. Diese Validierung wird üblicherweise durch Aushängen des betreffenden Dateisystems und Ausführen des Serviceprogramms fsck durchgeführt. Während dieses Vorgangs muss das System möglicherweise in den Einzelbenutzermodus gebracht werden. Daraus resultieren Ausfallzeiten, die proportional zur Größe des zu überprüfenden Dateisystems sind. Statt eines Serviceprogramms zum expliziten Ausführen der entsprechenden Überprüfungen besitzt ZFS einen Mechanismus zur regelmäßigen Überprüfung auf Inkonsistenzen. Diese als Bereinigung bezeichnete Funktion wird häufig in Arbeitsspeichern und anderen Systemen als Methode des Erkennens und Vermeidens von Problemen eingesetzt, die Hardwareausfälle oder Softwarefehlfunktionen verursachen.

Kontrollieren der ZFS-Datenbereinigung

Wenn ZFS einen Fehler erkennt (der auf die Bereinigung oder den Zugriff auf Dateien zurückzuführen ist), wird dieser intern protokolliert, sodass Sie einen schnellen Überblick über alle bekannten Fehler im Pool erhalten.

Explizite ZFS-Datenbereinigung

Die einfachste Methode zum Überprüfen der Datenintegrität besteht im Durchführen einer expliziten Bereinigung aller im Pool enthaltenen Daten. Diesem Vorgang werden alle Daten im Pool einmalig unterzogen, wodurch sichergestellt wird, dass alle Datenblöcke gelesen werden können. Die Bereinigung erfolgt so schnell, wie es das entsprechende Datenspeichergerät zulässt, obwohl E/A-Vorgänge eine niedrigere Priorität als normale Prozessen haben. Dieser Vorgang kann sich negativ auf die Systemleistung auswirken, obgleich die Daten des Pools während der Bereinigung weiterhin verwendbar und weitgehend verfügbar bleiben sollten. Explizite Bereinigungen können mit dem Befehl zpool scrub ausgeführt werden. Beispiel:

# zpool scrub tank

Der Status der aktuellen Bereinigung kann mithilfe des Befehls zpool status angezeigt werden. Beispiel:

# zpool status -v tank
  pool: tank
 state: ONLINE
 scrub: scrub completed after 0h7m with 0 errors on Tue Tue Feb  2 12:54:00 2010
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c1t0d0  ONLINE       0     0     0
            c1t1d0  ONLINE       0     0     0

errors: No known data errors

Pro Pool kann immer nur eine aktive Bereinigung ausgeführt werden.

Mithilfe der Option -s können Sie eine laufende Bereinigung stoppen. Beispiel:

# zpool scrub -s tank

In den meisten Fällen sollte eine Bereinigung vollständig abgeschlossen werden, um die Datenintegrität sicherzustellen. Falls sich eine Bereinigung negativ auf die Systemleistung auswirkt, können Sie sie jederzeit abbrechen.

Durch regelmäßige Bereinigungen wird kontinuierlicher E/A-Datenverkehr zu allen Datenträgern des Systems gewährleistet. Ein Nebeneffekt der Bereinigung besteht darin, dass die StromAdministration im Leerlauf befindliche Datenträger nicht in den Energiesparmodus schalten kann. Wenn das System E/A-Vorgänge jederzeit und ohne größere Störungen ausführen kann oder Stromverbrauch kein Problem ist, kann dieser Effekt problemlos ignoriert werden.

Weitere Informationen zur Interpretation der Ausgabe des Befehls zpool status finden Sie unter Abfragen des Status von ZFS-Speicher-Pools.

ZFS-Datenbereinigung und Resilvering

Nach dem Ersetzen eines Datenspeichergeräts wird ein so genanntes "Resilvering" (Wiederaufspielen von Daten) durchgeführt, um Daten von unbeschädigten Kopien auf den neuen Datenträger zu kopieren. Dieser Vorgang ist eine Form der Datenträgerbereinigung. Aus diesem Grunde kann in einem Pool immer nur ein solcher Vorgang stattfinden. Wenn ein Bereinigungsvorgang ausgeführt wird, unterbricht der Wiederherstellungsvorgang die aktuelle Bereinigung und startet sie nach Abschluss der Wiederherstellung neu.

Weitere Informationen zum Resilvering finden Sie unter Anzeigen des Resilvering-Status.

Beschädigte ZFS-Daten

Datenbeschädigung tritt auf, wenn sich Gerätefehler (die auf eines oder mehrere fehlende bzw. beschädigte Datenspeichergeräte hinweisen) auf virtuelle Geräte der obersten Hierarchieebene auswirken. So können beispielsweise in einer Hälfte einer Datenspiegelungskonfiguration Tausende Gerätefehler auftreten, ohne dass dies zur Datenbeschädigung führt. Wenn auf der anderen Seite der Spiegelung an genau derselben Stelle ein Fehler auftritt, werden die Daten beschädigt.

Eine Datenbeschädigung ist stets bleibend und muss bei der Reparatur besonders berücksichtigt werden. Auch wenn die betreffenden Datenspeichergeräte repariert oder ausgetauscht werden, sind die ursprünglichen Daten für immer verloren. Meist müssen Daten in solchen Situationen aus Sicherungskopien wiederhergestellt werden. Datenfehler werden beim Auftreten protokolliert und können durch regelmäßige Pool-Bereinigung (siehe folgender Abschnitt) in Grenzen gehalten werden. Beim Entfernen eines beschädigten Datenblocks erkennt der nächste Durchlauf der Datenträgerbereinigung, dass die Datenbeschädigung nicht mehr auf dem System vorhanden ist und entfernt die Protokollierung des Fehlers vom System.

Abhilfe bei ZFS-Speicherplatzproblemen

Prüfen Sie die folgenden Abschnitte, wenn Sie nicht sicher sind, wie ZFS die Speicherplatzberechnung bei Dateisystem und Pool protokolliert. Siehe auch Berechnung von ZFS-Festplattenkapazität.

Speicherplatzprotokollierung bei ZFS-Dateisystem

Mit den Befehlen zpool list und zfs list kann der verfügbare Speicherplatz im Pool und Dateisystem besser bestimmt werden als mit den früheren Befehlen df und du. Mit den Legacy-Befehlen kann nur schwierig zwischen Pool- und Dateisystemspeicherplatz unterschieden werden. Außerdem berücksichtigen die Legacy-Befehle den Speicherplatz nicht, der von untergeordneten Dateisystemen oder Schnappschüssen belegt wird.

Beispiel: Bei dem folgenden Root-Pool (rpool) sind 5,46 GB zugewiesen und 68,5 GB frei.

# zpool list rpool
NAME   SIZE  ALLOC   FREE  CAP  DEDUP  HEALTH  ALTROOT
rpool   74G  5.46G  68.5G   7%  1.00x  ONLINE  -

Wenn Sie die Speicherplatzberechnung für den Pool mit der Speicherplatzberechnung für das Dateisystem vergleichen, indem Sie die Spalte USED der einzelnen Dateisysteme prüfen, sehen Sie, dass der Poolspeicherplatz, der in ALLOC protokolliert wird, in der USED-Gesamtsumme des Dateisystems berücksichtigt wird. Beispiel:

# zfs list -r rpool
NAME                      USED  AVAIL  REFER  MOUNTPOINT
rpool                    5.41G  67.4G  74.5K  /rpool
rpool/ROOT               3.37G  67.4G    31K  legacy
rpool/ROOT/solaris       3.37G  67.4G  3.07G  /
rpool/ROOT/solaris/var    302M  67.4G   214M  /var
rpool/dump               1.01G  67.5G  1000M  -
rpool/export             97.5K  67.4G    32K  /rpool/export
rpool/export/home        65.5K  67.4G    32K  /rpool/export/home
rpool/export/home/admin  33.5K  67.4G  33.5K  /rpool/export/home/admin
rpool/swap               1.03G  67.5G  1.00G  -

Speicherplatzprotokollierung bei ZFS-Speicherpool

Der SIZE-Wert, der von dem Befehl zpool list protokolliert wird, besteht im Allgemeinen aus dem physischen Festplattenspeicher in dem Pool, variiert jedoch je nach Redundanzebene des Pools. Hierzu wird auf die folgenden Beispiele verwiesen. Der Befehl zfs list führt den verwendbaren Speicherplatz auf, der für Dateisysteme verfügbar ist, d.h. der Festplattenspeicher minus dem Overhead der Redundanzmetadaten des ZFS-Pools, sofern vorhanden.

Nicht-redundanter Speicherpool – Wenn ein Pool mit einer 136-GB-Festplatte erstellt wird, protokolliert der Befehl zpool list den Wert SIZE und den anfänglichen Wert FREE als 136 GB. Der anfängliche Speicherplatz AVAIL, der von dem Befehl zfs list protokolliert wird, beträgt 134 GB, aufgrund des kleinen Overheads durch die Poolmetadaten. Beispiel:
```
# zpool create tank c0t6d0
# zpool list tank
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank   136G  95.5K   136G     0%  1.00x  ONLINE  -
# zfs list tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank    72K   134G    21K  /tank
```
Gespiegelter Speicherpool – Wenn ein Pool mit zwei136-GB-Festplatten erstellt wird, protokolliert der Befehl zpool list den Wert SIZE als 136 GB und den anfänglichen Wert FREE als 136 GB. Diese Protokollierung wird als verkleinerter Speicherplatzwert bezeichnet. Der anfängliche Speicherplatz AVAIL, der von dem Befehl zfs list protokolliert wird, beträgt 134 GB, aufgrund des kleinen Overheads durch die Poolmetadaten. Beispiel:
```
# zpool create tank mirror c0t6d0 c0t7d0   
# zpool list tank
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank   136G  95.5K   136G     0%  1.00x  ONLINE  -
# zfs list tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank    72K   134G    21K  /tank
```
RAID-Z-Speicherpool – Wenn ein raidz2-Pool mit drei 136-GB-Festplatten erstellt wird, protokolliert der Befehl zpool list den Wert SIZE als 408 GB und den anfänglichen Wert FREE als 408 GB. Diese Protokollierung wird als vergrößerter Festplattenspeicherwert bezeichnet, der Redundanz-Overhead umfasst, wie Paritätsinformationen. Der anfängliche Speicherplatz AVAIL , der von dem Befehl zfs list protokolliert wird, beträgt 133 GB wegen des Poolredundanz-Overheads. Die Speicherplatzdiskrepanz zwischen der Ausgabe des Befehls zpool list und des Befehls zfs list für einen RAID-Z-Pool ist darauf zurückzuführen, dass zpool list den vergrößerten Poolspeicherplatz protokolliert.
```
# zpool create tank raidz2 c0t6d0 c0t7d0 c0t8d0
# zpool list tank
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank   408G   286K   408G     0%  1.00x  ONLINE  -
# zfs list tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank  73.2K   133G  20.9K  /tank
```

Reparieren beschädigter Daten

In den folgenden Abschnitten wird beschrieben, wie Sie den Typ der Datenbeschädigung ermitteln und (falls möglich) Daten reparieren können.

Ermitteln der Art der Datenbeschädigung
Reparatur beschädigter Dateien bzw. Verzeichnisse
Reparieren von Schäden am gesamten ZFS-Speicher-Pool

Zur Minimierung des Risikos von Datenbeschädigung nutzt ZFS Prüfsummenberechnung, Redundanz und Datenselbstheilung. Dennoch können Datenbeschädigungen auftreten, wenn ein Pool nicht redundant ist. Dies ist der Fall, wenn sich der Pool zum Zeitpunkt der Beschädigung in beeinträchtigtem Zustand befindet oder mehrere Datenkopien durch unvorhergesehene Ereignisse beschädigt werden. Unabhängig von der Ursache ist das Ergebnis dasselbe: Daten werden beschädigt und sind deswegen nicht mehr verfügbar. Die erforderlichen Abhilfemaßnahmen hängen von der Art der beschädigten Daten und ihrem relativen Wert ab. Es können zwei grundlegende Arten von Daten beschädigt werden:

Pool-Metadaten – Damit Pools geöffnet werden können und auf Datasets zugegriffen werden kann, muss ZFS eine Reihe spezieller Daten verarbeiten. Wenn diese Daten beschädigt sind, stehen der gesamte Pool bzw. ein Teil der Datasets nicht mehr zur Verfügung.
Objektdaten – In diesem Fall sind Daten innerhalb einer bestimmten Datei bzw. eines Verzeichnisses beschädigt. Dieses Problem kann dazu führen, dass auf einen Teil dieser Datei bzw. dieses Verzeichnisses nicht mehr zugegriffen werden kann oder das betreffende Objekt in seiner Gesamtheit nicht mehr verfügbar ist.

Daten werden während des Normalbetriebs und der Datenbereinigung auf Integrität überprüft. Weitere Informationen zum Überprüfen der Integrität von Pool-Daten finden Sie unter Überprüfen der Integrität des ZFS-Dateisystems.

Ermitteln der Art der Datenbeschädigung

Der Befehl zpool status zeigt standardmäßig nur an, dass eine Datenbeschädigung aufgetreten ist, es ist jedoch nicht ersichtlich, wo sie sich ereignet hat. Beispiel:

# zpool status monkey
  pool: monkey
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010
config:

        NAME        STATE     READ WRITE CKSUM
        monkey      ONLINE       8     0     0
          c1t1d0    ONLINE       2     0     0
          c2t5d0    ONLINE       6     0     0

errors: 8 data errors, use '-v' for a list

Ein Fehler zeigt lediglich an, dass zu einem bestimmten Zeitpunkt ein Fehler aufgetreten ist. Diese Fehler müssen nicht mehr notwendigerweise im System vorhanden sein. Unter normalen Bedingungen ist dies der Fall. Bestimmte zeitweilige Ausfälle können zu Datenbeschädigungen führen, die nach dem Ende des Ausfalls automatisch behoben werden. Bei einer vollständigen Bereinigung des Pools wird jeder aktive Datenblock im Pool untersucht, und das Fehlerprotokoll wird nach Abschluss der Bereinigung geleert. Wenn Sie sehen, dass die betreffenden Fehler im Pool nicht mehr auftreten und Sie nicht auf den Abschluss des Bereinigungsvorgangs warten möchten, können Sie alle Fehler im Pool mithilfe des Befehls zpool online löschen.

Wenn die Datenbeschädigung in Metadaten für den gesamten Pool aufgetreten ist, sieht die Befehlsausgabe etwas anders aus. Beispiel:

# zpool status -v morpheus
  pool: morpheus
    id: 1422736890544688191
 state: FAULTED
status: The pool metadata is corrupted.
action: The pool cannot be imported due to damaged devices or data.
   see: http://www.sun.com/msg/ZFS-8000-72
config:

        morpheus    FAULTED   corrupted data
          c1t10d0   ONLINE

Ist ein Pool beschädigt, wird er in den Status FAULTED versetzt, da er nicht die erforderliche Datenredundanz gewährleisten kann.

Reparatur beschädigter Dateien bzw. Verzeichnisse

Ist eine Datei oder ein Verzeichnis beschädigt, kann es je nach Art der Datenbeschädigung sein, dass das System noch immer funktioniert. Schäden sind praktisch nicht wieder rückgängig zu machen, wenn im System keine brauchbaren Datenkopien vorhanden sind. Wenn die betreffenden Daten wertvoll sind, müssen Sie diese aus Sicherungskopien wiederherstellen. Auch in diesem Fall kann es sein, dass Sie nach dieser Datenbeschädigung den Normalbetrieb wiederherstellen können, ohne das gesamte Pool wiederherstellen zu müssen.

Wenn sich der Schaden innerhalb eines Dateidatenblocks befindet, kann die betreffende Datei sicher gelöscht werden, wodurch der Fehler aus dem System entfernt wird. Mit dem Befehl zpool status -v können Sie eine Liste von Dateinamen mit dauerhaften Fehlern ausgeben. Beispiel:

# zpool status -v
  pool: monkey
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: http://www.sun.com/msg/ZFS-8000-8A
 scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010
config:

        NAME        STATE     READ WRITE CKSUM
        monkey      ONLINE       8     0     0
          c1t1d0    ONLINE       2     0     0
          c2t5d0    ONLINE       6     0     0

errors: Permanent errors have been detected in the following files: 

/monkey/a.txt
/monkey/bananas/b.txt
/monkey/sub/dir/d.txt
monkey/ghost/e.txt
/monkey/ghost/boo/f.txt

Es folgen Erläuterung zur Liste von Dateinamen mit dauerhaften Fehlern:

Wenn der vollständige Pfad zur Datei gefunden wurde und das Dataset eingehängt ist, wird der vollständige Pfad zur Datei angezeigt. Beispiel:
```
/monkey/a.txt
```
Wenn der vollständige Pfad zur Datei gefunden wurde, das Dataset jedoch nicht eingehängt ist, wird der Dataset-Name ohne vorangestellten Schrägstrich (/), gefolgt vom Pfad zur Datei innerhalb des Datasets angezeigt. Beispiel:
```
monkey/ghost/e.txt
```
Wenn die Objektnummer zu einem Dateipfad nicht erfolgreich konvertiert werden kann, weil ein Fehler auftrat oder dem Objekt kein realer Pfad zugewiesen ist (z. B. bei dnode_t), dann wird der Dataset-Name, gefolgt von der Objektnummer angezeigt. Beispiel:
```
monkey/dnode:<0x0>
```
Wenn ein Objekt im Metaobjekt-Set (MOS) beschädigt ist, wird ein spezielles Tag <metadata>, gefolgt von der Objektnummer, angezeigt.

Wenn Metadaten einer Datei bzw. eines Verzeichnisses beschädigt sind, kann die betreffende Datei nur an einen anderen Ort verschoben werden. Sie können Dateien bzw. Verzeichnisse sicher an eine unkritische Stelle kopieren, sodass das ursprüngliche Objekt am Ausgangsort wiederhergestellt werden kann.

Abhilfe bei beschädigten Daten mit mehreren Blockreferenzen

Wenn ein beschädigtes Dateisystem fehlerhafte Daten mit mehreren Blockreferenzen enthält, wie Schnappschüssen, kann der Befehl zpool status -v nicht alle fehlerhaften Datenpfade anzeigen. Die aktuelle zpool status-Protokollierung der beschädigten Daten wird durch den Umfang der Metadatenbeschädigung und außerdem dadurch begrenzt, ob Blöcke nach Ausführung des Befehls zpool status wieder verwendet wurden. Deduplizierte Blöcke machen die Protokollierung aller fehlerhaften Daten noch komplizierter.

Wenn fehlerhafte Daten vorhanden sind und der Befehl zpool status -v identifiziert, dass Schnappschussdaten betroffen sind, sollten Sie den folgenden Befehl ausführen, um zusätzliche fehlerhafte Pfade zu identifizieren:

Reparieren von Schäden am gesamten ZFS-Speicher-Pool

Wenn Pool-Metadaten beschädigt sind und der Pool dadurch nicht geöffnet oder importiert werden kann, stehen Ihnen folgende Optionen zur Verfügung:

Sie können versuchen, den Pool mithilfe des Befehls zpool clear -F oder zpool import -F wiederherzustellen. Mithilfe dieser Befehle wird versucht, die letzten Pool-Transaktionen zurückzusetzen, um den Pool wiederherzustellen. Sie können den Befehl zpool status verwenden, um einen beschädigten Pool und die empfohlenen Wiederherstellungsschritte anzuzeigen. Beispiel:

# zpool status
  pool: tpool
 state: FAULTED
status: The pool metadata is corrupted and the pool cannot be opened.
action: Recovery is possible, but will result in some data loss.
        Returning the pool to its state as of Wed Jul 14 11:44:10 2010
        should correct the problem.  Approximately 5 seconds of data
        must be discarded, irreversibly.  Recovery can be attempted
        by executing 'zpool clear -F tpool'.  A scrub of the pool
        is strongly recommended after recovery.
   see: http://www.sun.com/msg/ZFS-8000-72
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
         tpool      FAULTED      0     0     1  corrupted data
          c1t1d0    ONLINE       0     0     2
          c1t3d0    ONLINE       0     0     4

Für den in der vorhergehenden Ausgabe beschriebenen Wiederherstellungsvorgang wird folgender Befehl ausgeführt:

# zpool clear -F tpool

Wenn Sie versuchen, einen beschädigten Pool zu importieren, wird eine Meldung wie die folgende angezeigt:

# zpool import tpool
cannot import 'tpool': I/O error
        Recovery is possible, but will result in some data loss.
        Returning the pool to its state as of Wed Jul 14 11:44:10 2010
        should correct the problem.  Approximately 5 seconds of data
        must be discarded, irreversibly.  Recovery can be attempted
        by executing 'zpool import -F tpool'.  A scrub of the pool
        is strongly recommended after recovery.

Für den in der vorhergehenden Ausgabe beschriebenen Wiederherstellungsvorgang wird folgender Befehl ausgeführt:

# zpool import -F tpool
Pool tpool returned to its state as of Wed Jul 14 11:44:10 2010.
Discarded approximately 5 seconds of transactions

Wenn der beschädigte Pool in der Datei zpool.cache enthalten ist, wird das Problem behoben, sobald das System neu gestartet wird, und die Beschädigung des Pools wird über den Befehl zpool status angezeigt. Falls der Pool nicht in der Datei zpool.cache enthalten ist, kann er nicht importiert oder geöffnet werden, und es werden Meldungen angezeigt, die den beschädigten Pool betreffen, wenn Sie versuchen, den Pool zu importieren.

Sie können einen beschädigten Pool im schreibgeschützten Modus importieren. Mit dieser Methode können Sie den Pool so importieren, dass Sie Zugriff auf die Daten haben. Beispiel:
```
# zpool import -o readonly=on tpool
```
Weitere Informationen zum schreibgeschützten Importieren eines Pools finden Sie unter Importieren eines Pools im schreibgeschützten Modus.
Mit dem Befehl zpool import -m können Sie einen Pool mit einem fehlenden Protokolliergerät importieren. Weitere Informationen finden Sie unter Importieren eines Pools mit fehlendem Protokolliergerät.
Wenn der Pool durch keine der beiden Wiederherstellungsmethoden wiederhergestellt werden kann, müssen Sie den Pool und alle seine Daten aus einer Sicherungskopie wiederherstellen. Das eingesetzte Verfahren hängt weitgehend von der Pool-Konfiguration und der Datensicherungsstrategie ab. Zuerst sollten Sie die mit dem Befehl zpool status angezeigte Konfiguration speichern, um diese nach dem Löschen des Pools wiederherstellen zu können. Löschen Sie den Pool dann mit dem Befehl zpool destroy -f.

Legen Sie sich an sicherer Stelle eine Datei an, in der die Struktur der Datasets sowie die einzelnen lokal gesetzten Eigenschaften beschrieben sind, da diese Informationen nicht mehr zugänglich sind, wenn auf den Pool nicht mehr zugegriffen werden kann. Mithilfe der Pool-Konfiguration und der Dataset-Struktur können Sie nach dem Löschen des Pools die vollständige Konfiguration wiederherstellen. Danach können Sie mithilfe eines beliebigen Wiederherstellungsverfahrens den Pool wieder mit Daten „auffüllen“.

Navigationslinks überspringen
Druckansicht beenden
	Oracle Solaris ZFS-Administrationshandbuch Oracle Solaris 10 1/13 Information Library (Deutsch)