Wie macht Ihr die Backups Eurer Server????

[Frank]

Hallo,

mich würde mal interessieren wie Ihr Backups Eurer Server macht.
Mir geht es nicht um die Daten, sondern um den Server an sich.

Ich habe manchmal zwei FreeBSD installiert; davon eines nur zum sichern des anderen
mit dump.
Kann man eigentlich ein Live-System (ohne laufende "Dienste") zuverlässig "dumpen"?

In Zukunft möchte ich gerne Windows-Server, Windows-Clients und FreeBSD-Server über das Netzwerk sichern.

Was haltet Ihr von g4u?
Oder von Clonezilla?
Mir geht es darum, schnell Rechner neu aufsetzen zu können. Sprich ein altes Image zurückspielen.

Vielen Dank

 

[Daemotron]

Images mit der Grundinstallation und -konfiguration mache ich einfach per dd, bzip2 (und ggf. openssl bei Remote-Systemen) von einem Live- oder Rettungssystem aus. Das schöne daran ist, man kann sie auch dann erstellen und zurückspielen, wenn einem kein FreeBSD-Livesystem zur Verfügung steht - unter Linux funktionert dd genauso gut

 

[cla]

Images vom "fertigen" System nach der Installation mit "dump".
Je nach System dann während des Betriebes auch mit "dump" (Differienzell und Inkrementell).

Ich hab da ein nettes kleines Script, welches 1x Monat Full, 1x Woche Diff und täglich Inkrementell "dumps" erzeugt. Noch besser wäre es wenn es alte "dumps" recyclen/rotieren würde, damit man nicht immer auf den Speicherplatz achten müsste...aber da hatte ich noch keine Zeit das entsprechend anzupassen.

Dump unterstützt Snapshots...sichert somit einen konsistenten Zustand des Dateisystems. Einzig Datenbanken sichere ich noch extra über deren eingebaute Funktionen (sqldump oder ähnliches).

Bei ZFS-Pools verwende ich statt "dump" dann "zfs send/recv"

Daten werden von einem Backupserver zusätzlich mit "Bacula" (http://www.bacula.org) gezogen, gesichert und verwaltet).
Mit Bacula kannst du auch Windows, Linux, OS X was auch immer backuppen...allerdings ist Bacula nur bedingt für Bare-Metal-Recovery geeignet.
Bare-Metal bei BSD geschieht bei mir mit "dump".
Bei Windows verwende ich für Bare-Metal Imagetools wie "Shadowprotect" oder "i4w". Bei OS X "Superduper" und/oder "Chronosync"

Windows-Clients, welche Daten aus verschiedenen Gründen nicht auf dem Server ablegen können, sondern lokal speichern müssen (oft Reiselaptops), werden mit BackupPC (http://backuppc.sourceforge.net) gesichert. Allerdings bin ich damit nicht ganz so glücklich, da es bei manchen Usern Probleme verursacht, weil diese Superextralange Dateinamen und Ordnerverschachtelungen besitzen (rsync-Problem), und bei manchen Usern ziemlich hohe Systemlast erzeugt während des Backupvorgangs.


Warum "dump"? Weil ich auch die Möglichkeit habe ggf. einzelne Dateien zu extrahieren. Weil es zuverlässig und schnell läuft.

"dd": Das Argument von Ogion mit "dd" und der Möglichkeit ohne FreeBSD-Livesystem das ganze wiederherzustellen ist natürlich auch nicht von der Hand zu weisen. Aber "dd" sichert doch auch gelöschte Bereiche der Festplatte mit, falls sich dort "alte" Daten befinden sollten...ist das ganze nicht ziemlich Speicherfressend?

 

[Nonpareille]

Gar nicht.
Ich hab den Server so angelegt, dass im Falle des zerschossenen Systems eine Neuinstallation schnell über die Bühne geht. Muss aber auch zugestehen, dass ein Ausfall des Servers bei mir, obwohl "Produktivsystem", keine Katastrophe darstellt, solange die relevanten Daten irgendwo noch vorhanden sind.

 

[Azazyel]

mich würde mal interessieren wie Ihr Backups Eurer Server macht.
Mir geht es nicht um die Daten, sondern um den Server an sich.

Im Beitrag von cla steht eigentlich schon fast alles zum Thema, ich ergänze nur noch ein paar Sachen aus eigener Erfahrung.

Kann man eigentlich ein Live-System (ohne laufende "Dienste") zuverlässig "dumpen"?

Bis auf Datenbanken - man sollte deren hauseigene Tools für das Backup verwenden - geht das völlig problemlos.

Zum Thema dd:
Das ist nur in Sonderfällen zu gebrauchen, weil es schlecht im laufenden Betrieb geht und im Gegensatz zu den anderen Lösungen die Größe der Partitionen usw. fest speichert (und viel Platz braucht). Dafür ist es extrem simpel: Von CD booten und dd if=/dev/xyz | gzip | ssh remotehost "cat > mybackup.dd.gz" ist manchmal einfach das Mittel der Wahl und völlig OS-unabhängig.

Für mich ist inzwischen Virtualisierung (egal ob VirtualBox/Xen/VMware/KVM/xVM) das Mittel der Wahl.

Vorteile:

• Backups einfach per Snapshot erstellen und wegsichern
• Keinerlei Probleme bei Migration/Restore auf anderen Rechner
• Sicherung im laufenden Betrieb ohne Gefahr von Inkonsistenzen (z.B. Datenbanken)
• eine Sicherungsmethode für alle OS

Nachteile:

• benötigt mehr Resourcen (CPU/RAM/Speicherplatz)
• die Wahl der richtigen Virtualisierung ist eine tückische Frage

 

[cla]

Für mich ist inzwischen Virtualisierung (egal ob VirtualBox/Xen/VMware/KVM/xVM) das Mittel der Wahl.

[*]Sicherung im laufenden Betrieb ohne Gefahr von Inkonsistenzen (z.B. Datenbanken)

Kannst du hierauf näher eingehen? Wiso soll es bei Virtualisierung plötzlich kein Problem mehr sein? (Wenn man von laufenden Systemen ausgeht).

Bzw....auf welche Virtualisierung beziehst du dich, und wie gehst du dort genau beim Backup vor?

(bin auch grad dabei Server von physikalisch -> virtuell überzuführen (VMWare ESX 3.5) und bin mir dort beim Backup noch nicht ganz schlüssig)

 

[Azazyel]

Kannst du hierauf näher eingehen? Wiso soll es bei Virtualisierung plötzlich kein Problem mehr sein? (Wenn man von laufenden Systemen ausgeht).

Beim virtualisierten System sichere ich ja das komplette Abbild des Servers, also nicht nur die Datenbank, wie sie just auf der Platte liegt, sondern auch etwaige ausstehende Transaktionen im RAM (bzw. im laufenden Prozess des DBMS) des Rechners.

Bei Wiederherstellung des Snapshots werden also auch die ausstehenden Transaktionen - je nach Natur der Anwendung - entweder per rollback abgebrochen (wenn z.B. die Transaktion an eine Netzwerkverbindung geknüpft ist, die bei Wiederherstellung nicht mehr da ist) oder per commit auf die Platte geschrieben.

So oder so, ich habe hinterher einen konsistenten Zustand der Datenbank (für die reine Sicherung der Daten sind natürlich nach wie vor die DBMS-eigenen Tools das Mittel der Wahl, aber es ging ja um Server-Sicherung im laufenden Betrieb).

Bzw....auf welche Virtualisierung beziehst du dich, und wie gehst du dort genau beim Backup vor?

Das oben beschriebene Szenario geht zumindest bei VMware (u.a. ESX(i), Workstation, Server) und VirtualBox, beim Rest bin ich mir nicht sicher, ob und wie das unterstützt wird.

Erlebt habe ich es selber bei einer ESX 4 (mit VMware Consolidated Backup):
Das Netzteil eines Servers ist früh morgens abgeraucht; der letzte Snapshot wurde während des nächtlichen, automatischen Datenimports erstellt. Die Datenbank war nach Wiederherstellung konsistent, die letzte Transaktion wurde abgebrochen (die Datenquelle im Netz war nicht mehr verfügbar). Ein simpler Neuanstoß des Imports hat die ganzen Angelegenheit ohne aufwendiges Restore der Datenbank wieder ins Lot gebracht.

(bin auch grad dabei Server von physikalisch -> virtuell überzuführen (VMWare ESX 3.5) und bin mir dort beim Backup noch nicht ganz schlüssig)

Vorsicht ist die Mutter der Porzellankiste, ich würde - je nachdem, wieviel Aufwand angebracht ist - zweigleißig fahren: Sicherung sowohl der VMs als auch der Datenbank selbst. Im Endeffekt kann auch bei der VM irgendetwas schiefgehen; Server kann man aber notfalls einfach neu installieren. Verlorene Daten sind unersetzbar.

 

[Daemotron]

"dd": Das Argument von Ogion mit "dd" und der Möglichkeit ohne FreeBSD-Livesystem das ganze wiederherzustellen ist natürlich auch nicht von der Hand zu weisen. Aber "dd" sichert doch auch gelöschte Bereiche der Festplatte mit, falls sich dort "alte" Daten befinden sollten...ist das ganze nicht ziemlich Speicherfressend?

Ja, ist es. Aber wie gesagt, ich nutze dd nur, um von einer frischen Installation (Platten(n) vorher genullt => lässt sich gut komprimieren) ein Image zu erstellen, mit dem ich das System (meine Kisten stehen fast alle remote) schnell wieder ans rennen kriege. Konfigurationsdateien und andere Nutzdaten werden natürlich nicht über dd gesichert.

Bei mir sieht ein Recovery-Prozess also so aus:

1. Image raufbügeln
2. System wieder auf den letzten Stand hochziehen (make buildworld)
3. Dienste installieren (die Package-Base aus meinen Tinder-Jails wird immer schön gesichert; Installation geht also sehr fix)
4. Konfigurationsdateien aus meinem lokalen Repository auschecken und rüberspielen
5. Nutzdaten zurücksichern
6. Kiste losfeuern und fertig.

Ich hab auch schon mal überlegt, ob man nicht einfach / als git- oder mercurial-Repo initialisieren könnte. Remote kann man es ja dann mit push sichern. Hat das schon mal jemand probiert?