Größere Backups & Rebuild

[weshalb]

Hallo, ich würde gerne wissen, wie man nervenschonend ein Rebuild aus dem vorhandenen Backup (rsnapshot) macht und ob man das nicht irgendwie auch automatisieren könnte.

Nehmen wir das Beispiel Mailserver. Bei wenigen Clients und dem Umzug auf einen neuen Server mag das ja alles noch gehen, doch bei vielen Usern stelle ich mir das schwierig vor, da man jedesmal händisch die Rechte der Dateien wieder anpassen muss.

Wie wird soetwas eigentlich in größeren Umgebungen gehandhabt?

[hec_tech]

Wir arbeiten da eigentlich anders.

Die Daten liegen auf NetApps. Die Hosts mounten die Daten per NFS oder iSCSI oder eben auch CIFS je nachdem welche Daten. Wir erstellen auf der NetApp einen Snapshot und fertig. Wenn irgend ein Problem auftritt kann ich entweder wie bei NFS die entsprechenden Daten aus dem .snapshot Verzeitnis kopieren oder falls mehr notwendig ist erstelle ich mit dem Snapshot einen FlexClone.

Den Clone kann ich dann einfach mounten. Das ist dann das gleiche Vorgehen wie bei einem Kryptotrojaner. Da habe ich maximal einen Datenverlust von 1h.

Alles was das mit dem Storage gemacht werden kann sollte das Storage machen damit bleiben die Systeme meist recht einfach.

[weshalb]

OK. Also liegen die Daten der User, beispielsweise Homeordner, auf einem Extra Storage, welches gesnapshotet wird.

Doch wie bekommt man im Falle eines Neuinstalls die User selbst wieder mit ins Boot?

[bluestar]

Doch wie bekommt man im Falle eines Neuinstalls die User selbst wieder mit ins Boot?

User liegen in größeren Umgebungen in einem zentralen Benutzerverzeichnis z.B. LDAP.

[weshalb]

Also mal ganz blöd gefragt:

Ich setze den Server neu auf, richte beispielsweise LDAP mit den bisherigen Nutzerdaten wieder ein und binde das System wieder an das Storage an und alles ist so, wie vorher?

Ich werde mich mit LDAP auseinander setzen müssen.

[heisenberg]

Oder Du machst schlicht und einfach ein Komplettbackup vom Server?

Ein rsnapshot-Backup kann man auch wiederherstellen, mal vorausgesetzt, dass es mit --numeric-ids und ansonsten vollständig gesichert wurde.

Wenn's um die BareMetal-Recovery geht, dann ist ein Imagebackup immer noch am brauchbarsten, weil am schnellsten und stressfreisten/einfachsten wieder herzustellen. Aber das Wort "Imagebackup" löst ja jetzt wahrscheinlich wieder Stürme der Entrüstung aus und vor allem endlose Diskussionen, welche Backupmethode die beste ist.

[hec_tech]

Welche Backup Methode zu verwenden ist hängt von den Anforderungen ab.

Wenn man einen Server sehr schnell wieder verfügbar haben muss ist ein restore von einem Image meist ein Problem wegen zu langer Laufzeit.

Die einfachste Variante ist sicher mit dd ein Image zu machen. Man kann aber auch / auf NFS legen. Damit ist man dann überhaupt am besten bedient und kann sehr schell Clones machen.

Jedes Backup wie auch die Zeiträume wie lange man die Backups aufzuheben hat ist aber eine Entscheidung des Unternehmens.

[bluestar]

Welche Backup Methode zu verwenden ist hängt von den Anforderungen ab.

Und letztendlich auch von der Risikoanalyse, mal so ein paar Fragen:
* Welche Art von Datenverlust will man/muss man abfedern?
* Sind ggfs. unterschiedliche Backup-Strategien für unterschiedliche Daten auf dem Server sinnvoll?
* Welche Ausfallzeiten sind tolerierbar?
* Welche Gründe für ein Disaster Recovery (=Rücksicherung als Vollbackup) gibt es?
* Gibt es vorbereitende Maßnahmen um den Fall eines Disaster Recovery möglichst vermeiden zu können?
* Können wir die allgemeine Sicherheit des Servers erhöhen? (RAID, USV, redundantes Netzteil, Ersatzhardware baugleich bereithalten)
* Setzt man neben dem Server ein zentrales Storage ein?

Wir verwenden eine Kombination aus ZFS & Snapshots, inkrementelle Snapshots auf Backup-Server, Bareos, bei Mail, DB jeweils Systeme im Clusterbetrieb und aktives Monitoring um Ausfälle/Datenverlust vorbeugen zu können.

[heisenberg]

Jo! Die Diskussion geht wieder los

Grundsätzlich scheint mir hier ein Unterschied da zu sein zwischen dem Umgebungen von weshalb auf der einen Seite und hec_tec, sowie bluestar auf der anderen Seite. weshalb scheint mir da eher privat/soho zu sein und das andere eher etwas enterpreisig. Insfoern passen die Anforderungen und Lösungen da vielleicht nicht ganz zusammen.

[bluestar]

Da muss ich allerdings mal widersprechen, die Frage von weshalb:

Wie wird soetwas eigentlich in größeren Umgebungen gehandhabt?

Ich bin d'accord eine SoHo-Umgebung und eine Enterprise-Umgebung kann man nicht vergleichen. Eine Enterpise-Lösung für weshalb zu beschreiben wird niemals in einer Universalantwort oder Blaupause enden, da beides schlicht nicht existiert.

[heisenberg]

Da muss ich allerdings mal widersprechen, die Frage von weshalb:

Wie wird soetwas eigentlich in größeren Umgebungen gehandhabt?

Ähem. Ja. Sorry. Habe ich wohl irgendwie überlesen.

[weshalb]

Welche Backup Methode zu verwenden ist hängt von den Anforderungen ab.

Und letztendlich auch von der Risikoanalyse, mal so ein paar Fragen:
* Welche Art von Datenverlust will man/muss man abfedern?
* Sind ggfs. unterschiedliche Backup-Strategien für unterschiedliche Daten auf dem Server sinnvoll?
* Welche Ausfallzeiten sind tolerierbar?
* Welche Gründe für ein Disaster Recovery (=Rücksicherung als Vollbackup) gibt es?
* Gibt es vorbereitende Maßnahmen um den Fall eines Disaster Recovery möglichst vermeiden zu können?
* Können wir die allgemeine Sicherheit des Servers erhöhen? (RAID, USV, redundantes Netzteil, Ersatzhardware baugleich bereithalten)
* Setzt man neben dem Server ein zentrales Storage ein?

Wir verwenden eine Kombination aus ZFS & Snapshots, inkrementelle Snapshots auf Backup-Server, Bareos, bei Mail, DB jeweils Systeme im Clusterbetrieb und aktives Monitoring um Ausfälle/Datenverlust vorbeugen zu können.

Also das ist ja schonmal recht aufschlussreich. Bisher administriere ich eher kleinere Umgebungen, wobei das Rebulding und die Ausfallzeiten nicht so sehr ins Gewicht fallen. Trotzdem wäre es nicht schlecht, schon alleine um sich das Leben zu erleichtern, etwas mehr KnowHow einfließen zu lassen.

[hec_tech]

Ob man jetzt ZFS oder WAFL einsetzt macht nicht mehr so viel Unterschied.

Die beiden Filesystem sind ähnlich. Wichtig ist auf jeden Fall eine Sicherung mit Snapshots. Diese können sehr schnell wiederhergestellt werden.
Die andere Frage ist immer was mache ich bei wirklichen Totalausfällen eines Standortes durch Feuer oder andere Katastrophen.
Wir lösen das mit einem MetroCluster. Dies ist zwar nicht ganz billig aber ich kann jederzeit das Storage von einem auf den anderen Standort umschalten. Das ist für die Clients transparent.
Natürlich muss vom Primärsystem auch einen Datenübertragung auf eine Nearstore stattfinden. Hier kann ich auch mehr Snapshots haben als am Primärsystem. Meist sind in den Nearstores auch nur langsame SATA Disken zu finden.

Backup to Tape würde ich nicht mehr machen. Es ist einfach zu langsam. Wenn man von wirklich von Tape restoren muss ist einfach die Downtime zu hoch.
Weiters ist es wie eben sinnvoll die Anwendungen zu Clustern wobei die Nodes immer auf beide Datacenter aufgespalten werden.

[bluestar]

Also das ist ja schonmal recht aufschlussreich. Bisher administriere ich eher kleinere Umgebungen, wobei das Rebulding und die Ausfallzeiten nicht so sehr ins Gewicht fallen. Trotzdem wäre es nicht schlecht, schon alleine um sich das Leben zu erleichtern, etwas mehr KnowHow einfließen zu lassen.

Ich würde an deiner Stelle versuchen, die Notwendigkeit von Restores auf ein Minimum zu reduzieren. Auch in kleineren Umgebungen kannst du beispielsweise ZFS mit Snapshots (über's Netz in einen anderen Brandabschnitt ) einsetzen.

[heisenberg]

Wie sieht es denn da mit der Konsistenz bei Euren Snapshots aus?

Konsistenz speziell bzgl. einer Datenbank oder einer anderen Applikation die Livedaten hat, die nicht zwangsläufig konsistent sind und die, wenn Sie dann mit diesem Snapshot, der aus dem laufenden Betrieb durchgeführt wurde hochgefahren werden. Stichwort: "Quiesce".

Unter Windows ist da wohl per Default Funktionalität die da wohl eine Art von "Quiesce"-Status auslöst, wonach z. B. ein SQL-Server erst mal auf Pause geht bzw. seine Transaktionen abschließt, etc. Unter Linux gibt es das meines Wissens nach nicht. Da müssten man dann ja entweder die Dienste anhalten oder das ganze System herunterfahren. Das ist der Grund, warum ich Snapshots nicht mag, weil ich nicht verstanden habe, wie ich die Konsistenz da gewährleisten kann, bzw. vermute dass das so erstmal unsauber ist. Oder nicht mag, weil das zusätzlichen Aufwand nach sich ziehen würde, diese Shutdowns zu implementieren und weil Downtime in meinem Fall grundsätzlich auch wieder Kundenkommunikation nach sich zieht.

Einfache Lösung wäre natürlich von diesen speziellen Daten zusätzlich Backups anzulegen(z. B. Datenbankdumps,...), die dann separat zurückgespielt werden müssten.

[bluestar]

Wie sieht es denn da mit der Konsistenz bei Euren Snapshots aus?

Das ist je nach Datenbestand eine eigene Aufgabe, aber da du konkret nach Datenbanken gefragt hast bei PostgreSQL lösen wir das wie folgt:

Code: Alles auswählen

psql -c "select pg_start_backup('hot_backup');"
zfs snapshot ......
psql -c "select pg_stop_backup();"

Unsere eigene Anwendung hat ebenso eine API zum Ein-/Ausschalten des Backup-Modus und währenddessen werden keine Daten auf das Storage geschrieben.

[hec_tech]

Diese Technogie die du unter Windows kennst gibt es auch für Linux.

Sicherlich sollte man den Restoreaufwand auf ein Minimum beschränken nur leider ist es manchmal notwendig. Dann muss der Restore aber schnell gehen.
Eine SQL Datenbank mit vielen TB kann ich in wenigen Minuten wieder online bekommen. Das funktioniert nur Snapshots. Wenn ich mehrere TB kopieren muss dauert das zu lange. Der Systemstillstand kostet sehr viel. Da ist die Investition meist die günstigere Alternative. Leider sieht es die Geschäftsführung anders - bis zum ersten Stillstand.

Ich kann auch die Integrität des Snapshots mit Verfication überprüfen. Beispielsweise bei Oracle Datenbanken oder eben auch SQL Server.

[heisenberg]

Ok. D. h. da wird dann eine Zusatzsoftware installiert, die das tut?

[hec_tech]

Ja das sind Plugins damit lässt sich das problemfrei durchführen - man kann sich auch selbst Plugins schreiben. Die müssen gewisse Funktionen haben und manche sind eben optional.

[heisenberg]

Diese Technogie die du unter Windows kennst gibt es auch für Linux.

Sicherlich sollte man den Restoreaufwand auf ein Minimum beschränken nur leider ist es manchmal notwendig. Dann muss der Restore aber schnell gehen.
Eine SQL Datenbank mit vielen TB kann ich in wenigen Minuten wieder online bekommen. Das funktioniert nur Snapshots. Wenn ich mehrere TB kopieren muss dauert das zu lange. Der Systemstillstand kostet sehr viel. Da ist die Investition meist die günstigere Alternative. Leider sieht es die Geschäftsführung anders - bis zum ersten Stillstand.

Ich kann auch die Integrität des Snapshots mit Verfication überprüfen. Beispielsweise bei Oracle Datenbanken oder eben auch SQL Server.

Das gibt's also nicht als OSS. Mit welchen Produkten arbeitest Du da?

[hec_tech]

NetApp in Verbindung mit SnapCenter bzw früher mit SnapManager.

[weshalb]

NetApp in Verbindung mit SnapCenter bzw früher mit SnapManager.

Was kostet so eine Lösung eigentlich und gibt es gute Möglichkeiten, die nichts kosten?

[bluestar]

Was kostet so eine Lösung eigentlich

Wir haben mal ein redundantes Storage eines anderen Herstellers verbaut und da lagen die Kosten inkl. 10GB SAN Netz bei ca. 60.000€, Nutzkapazität 20TB.

und gibt es gute Möglichkeiten, die nichts kosten?

Linux+DRBD+ZFS+eigene Scripte

[weshalb]

Wir haben mal ein redundantes Storage eines anderen Herstellers verbaut und da lagen die Kosten inkl. 10GB SAN Netz bei ca. 60.000€, Nutzkapazität 20TB.

Ui, andere Klasse

Linux+DRBD+ZFS+eigene Scripte

Danke. Was brauche ich zu Hause, um sowas mal nachzubilden? Habe leider nur ein paar Microserver und ein paar olle Intelrechner am Start. Gestaltet sich der Aufbau als sehr schwierig?

[bluestar]

Linux+DRBD+ZFS+eigene Scripte

Danke. Was brauche ich zu Hause, um sowas mal nachzubilden?

Viel Freizeit

Habe leider nur ein paar Microserver und ein paar olle Intelrechner am Start. Gestaltet sich der Aufbau als sehr schwierig?

Das kommt auf dein Ziel an, wenn du das zum Üben aufbauen willst, dann kannst du 4 VMs nehmen und das nachstellen.
Planst du einen reellen Einsatz, so brauchst du 4 Server, zwei für‘s Storage, zwei für‘s Hosting und zwei dedizierte Switches, die Spanning-Tree und Trunking können.
Die Server brauchen je 3 besser 4 Netzwerkkarten.

Bild zum Aufbau: