Meine Erfahrung mit ZFS ist im Allgemeinen, dasses funktioniert einfach, daher gehe ich davon aus, dass die Antwort lauten wird, dass es kein Problem ist – aber ich habe einen Datenpool, der mir den Januar ruinieren wird, wenn er schiefgeht, also möchte ich das noch einmal überprüfen.
Diese Frage könnte eigentlich in zwei unterschiedlichen Situationen auftauchen, in denen es um einen separaten Datenpool geht. Im Moment beschäftige ich mich mit der ersten, aber ich habe mich auch über die zweite Gedanken gemacht:
- Der Speicher für die Systemfestplatte (also der, der enthält
rpool) fällt aus, aber der Speicher für den Datenpool ist in Ordnung. Sie möchten also die Systemfestplatte aus Sicherungen wiederherstellen, aber einfach mit dem Live-Speicher des Datenpools weitermachen. - Sie haben Solaris in einer VM ausgeführt und möchten zu einem Snapshot zurückkehren, den der Hypervisor erstellt hat (nichtein ZFS-Snapshot von
rpool), aber der Datenpool ist auf Festplatten im „unabhängigen“ Modus, RDMs usw. gespeichert und wird daher nicht zurückgesetzt.
In beiden Fällen wird Solaris beim erneuten Hochfahren auf einen Datenpool stoßen, den es zwar kennt, der sich jedoch in einem Zustand befindet, in den es ihn (soweit es sich erinnern kann) nie gebracht hat.
Mich interessiert hauptsächlich nur der Fall, in dem das System vor dem Zurückspulen der Systemfestplatte sauber heruntergefahren wurde und in dem das System vor dem Zurückspulen auf das Image sauber heruntergefahren wurde. Ich würde erwarten, dass das Umschalten zwischen den Betriebszuständen etwas schwieriger sein könnte.
Beachten Sie auch, dass sich in meinem speziellen Fall die Speichergeometrie des Pools und die Pfade zum Speicher nicht geändert haben. Auch hier würde ich erwarten, dass dies schwieriger wäre, wenn dies der Fall wäre.
Ich würde das bei Windows und NTFS nicht einmal fragen, da es sich dabei um ein vergleichsweise einfaches entkoppeltes System handelt und es daher schwer zu verstehen ist, warum eswürde nichtArbeit. Es scheint jedoch, dass Solaris eine Art Pool-Metadaten speichertaußerhalb der Bandbreite, wie die Tatsache zeigt, dass Sie dies tun sollen zpool exportund zpool importwann Sie Pools zwischen Systemen verschieben (was ich dank VMware nie auf diese Weise getan habe). Meine Kenntnisse dieser Metadaten und ihres Zwecks sind begrenzt, daher fällt es mir schwer, die Auswirkungen in dieser Situation zu beurteilen. (Eine Erklärung hierzu wäre großartig!)
Ich habe tatsächlich noch Zugriff auf das System vor dem Rollback. Es befindet sich in einem VMFS-Datenspeicher, der von einem HP SmartArray unterstützt wird, das nach einem unglückseligen Festplattenwechsel zur vorbeugenden Wartung (bei dem Daten verloren gingen, weil SmartArray dümmer ist als ZFS) eine 1716-POST-Warnung ausgab. Alle wichtigen VMs scheinen noch in Ordnung zu sein und Scans ihrer Dateisysteme haben keine Fehler ergeben, aber ich habe trotzdem vor, das Array aus einem sehr aktuellen Backup wiederherzustellen, da ich Grund zu der Annahme habe, dass ESXisetzt fehlerhafte Sektoren stillschweigend auf Null, anstatt die Fehler an die Gäste weiterzugeben, daher möchte ich nicht das Risiko eingehen, dass irgendwo ein auf Null gesetzter Sektor lauert, der mir später auf die Füße fallen könnte.
Bei der Solaris-VM muss ich mir keine Gedanken über auf Null gesetzte Sektoren machen, da ZFS das erkennen würde, aber die meisten anderen VMs verwenden dumme Dateisysteme. Das Backup ist jedoch ein Image des gesamten VMware-Datenspeichers, sodass durch das Korrigieren dieser Sektoren auch die Solaris-VM zurückgesetzt wird. Tatsächlich habe ich diese rpoolVM bereinigt und dabei keine Fehler gefunden, also könnte ich, wenn ich wollte, einfach ihre VMDK woanders speichern und sie nach dem Rollback wieder hineinkopieren, und dann wäre diese ganze Frage hinfällig. Ich schätze, das werde ich tun, wenn niemand antwortet, lol. Aber das ist etwas, was ich mich schon eine Weile gefragt habe, also werde ich trotzdem fragen.
Die Frage ist also:kann ich einfach fortfahren und den Speicher der Systemfestplatte zurücksetzen und damit fertig sein? Oder müsste ich den Pool aus dem System vor dem Rollback exportieren, ein Rollback durchführen, den Pool löschen, bevor ich seinen Speicher anschließe, dann den Speicher anschließe und den Pool importieren? Letzteres klingt nicht so gut für mich, teilweise weil sowohl CIFS als auch iSCSI von diesem Pool aus bedient werden und ich mich nicht spontan daran erinnere, wie ich diese eingerichtet habe oder wie ich das überhaupt mache. Wenn sie also kaputtgehen, werde ich wütend. (Kann man merken, dass wir keinen Vollzeit-Systemadministrator haben? lol)
Auf der VM läuft eine ältere Version, Solaris 11.0.
(Übrigens ist es teilweise wegen derselben Frage älter. Ich wollte vor dem Upgrade-Versuch einen Snapshot der VM machen, für den Fall, dass ich es vermassle, aber dann machte ich mir Sorgen darüber, wie ein zurückgesetztes System auf den unabhängigen Pool reagieren könnte, also ließ ich es einfach so. Und ja, mir ist klar, dass ich auch einen Snapshot machen könnte rpool, aber das bietet nicht denselben Komfort für jemanden, der nicht täglich mit Solaris arbeitet.)
Antwort1
Dies ist eine dieser Antworten vom Typ „ZFS funktioniert einfach“ …
Die Metadaten des Pools werden tatsächlich im Pool gespeichert, nicht auf dem lokalen Betriebssystem. Wenn also beispielsweise ein System abstürzt und nicht sauber heruntergefahren wird, wissen die Metadaten im Pool, dass der Pool nicht sauber „exportiert“ wurde. Wenn Sie versuchen würden, diesen Pool in ein neues System zu importieren, würden Sie Beschwerden erhalten, dass er nicht exportiert wurde und zu einem anderen System gehört. An diesem Punkt würden Sie einfach ein zpool import -f (force) ausführen und er wird sauber zurückkommen.
Speziell für Ihren Datenpool wären die Daten darauf also sicher, egal wann/wo Sie versucht haben, den Pool erneut zu importieren. Wenn Sie einen „wiederhergestellten“ Rpool booten würden, wüsste das Betriebssystem auf diesem Rpool über die Pools Bescheid, die es importieren soll, und würde einfach den Datenpool importieren. Es verfolgt nicht, ob ein Pool exportiert wurde oder nicht, abgesehen von der Tatsache, dass das Betriebssystem nach dem Export eines Pools überhaupt nicht mehr damit Schritt hält.
Nun zur Rpool-Frage. Die Wiederherstellung aus einem VM-Snapshot, einer Bandsicherung oder was auch immer ändert nichts an der Art und Weise, wie der Datenpool gehandhabt wird, es sei denn, die Sicherung wurde erstellt, bevor der Datenpool überhaupt erstellt oder importiert wurde. In diesem Fall würden Sie den Pool einfach importieren, sobald das Betriebssystem wiederhergestellt ist. Die Daten im Datenpool sind sicher, unabhängig vom Zustand des Rpools.
Ich hoffe das hilft.
Nebenbei erwähnten Sie Ihre Zurückhaltung beim Upgrade von Solaris, weil Sie nicht sicher waren, wie es auf den Datenpool reagieren würde. Machen Sie sich darüber keine Sorgen. Bei einem Upgrade bleiben bekannte Pools erhalten und werden bei Bedarf importiert.
Beachten Sie auch, dass Upgrades des Solaris-Betriebssystems in sich geschlossene individuelle „Boot-Umgebungen (BE)“ sind. Wenn Sie also ein Betriebssystem-Upgrade durchführen, wird tatsächlich eine vollständig unabhängige Betriebssysteminstallation mit der neuen Version erstellt … während Ihr Betriebssystem noch aktiv ist. Wenn Sie dann neu starten, wird es auf dem neuen Betriebssystem gestartet. Wenn es Probleme mit dem neuen Betriebssystem gibt – z. B. unerwartete Änderungen an Bibliotheken usw. – können Sie einfach erneut starten und zur ursprünglichen Version 11.0 wechseln. Diese befindet sich dann im exakt gleichen Zustand wie vor dem Upgrade. Dies ist eine großartige Möglichkeit, Betriebssystem-Upgrades durchzuführen!