Fullbackup via SSH, inkrementell ohne DUMP

[409Coffemaker]

Hi zusammen,

nachdem ich einiges über Backuplösungen gelesen habe, möchte ich euch nun fragen:
Was hat sich in der Praxis bewährt?

Ich habe bisher immer mittels DUMP

Code: Select all

dump -0a -z9 /dev/hda3 -f - | ssh backup@xxx.xxx.xxx.xxx dd of=/backup/server1

per Cron ein wöchentliches Fullbackup auf meinen zweiten Server im RZ gemacht.

Da ich in einer Newsgroup ein Zitat von Linus Torvalds zum Thema DUMP gelesen habe und daraus hervorging „maybe dump works a thousand times fine for you, but you're are playing russian roulette with your backups“, gefolgt von dem Hinweis besser tar und cpio zu nutzen, bin ich nun unsicher.

tar und cpio benötigen doch das unmounting des jeweiligen Filesystem, oder? Das möchte ich nicht, der der Server im produktiv/lve Betrieb backupped werden sollte.

Was ist hier von zu halten?

Schön wäre, wenn jemand eine katastrophengeteste/bewährte Lösung anzeigen könnte!


Liebe Grüße

Yves

[ZX-81]

Was hat sich in der Praxis bewährt?

Backup mit rdiff-backup

Schön wäre, wenn jemand eine katastrophengeteste/bewährte Lösung anzeigen könnte!

Hatte vor kurzem die Katastrophe, Festplatte hat sich langsam verabschiedet und im letzten Backup hat der Inhalt von "/var" deswegen gefehlt. Mit den meisten anderen Backupverfahren hätte ich jetzt ein massives Problem gehabt, so musste ich nur einen weiteren Tag zurückgehen.

[409Coffemaker]

Hi,

was ist genau der Vorteil gegenüber tar, wenn man mal von der Bandbreitennutzung absieht (habe 6mbit nach zuhause und 100Mbit RZ-intern).


Yves

[ZX-81]

rdiff-backup hält den den letzten Stand direkt und den Rest als gezippte Differenzen darauf. Das ist so effektiv, dass ich bei meinem Rootserver auf jeden Tag der letzten 2 Jahre zurückgehen könnte und das Backup dafür belegt weniger als 10 GB (Server Root hat selbst ca 3 GB) und ich hatte bisher auch viel unnötiges noch im Backup (z.B. Kernelsourcen)

[409Coffemaker]

Alles klar, ich werde es ausprobieren. Ich vertrau dir voll und ganz


Liebe Grüße

Yves

[409Coffemaker]

Funktioniert wunderbar!

Vielen Dank!


Lg, Yves

[gabelhonz]

Wieso wird hier kein rsync genannt ?? hmmm
Also ich würde mit dd nen image machen und dann einmal die Woche per rsync das ganze Syncen !
Rsync ist ein spitzen Tool !

oder man lese hier: http://forums.gentoo.org/viewtopic.php?t=203530


gruß

[409Coffemaker]

Soviel ich weiss baut rdiff-backup auf rsync auf… laut Portage Info „more reliable“.

Yves

[gabelhonz]

hmm hab ich noch nie getestet, na dann werd ichs mir mal anschauen !
gruß

[409Coffemaker]

Ich finde rdiff-backup recht gut.
Das einzige was mich stört ist, das es einzelne Files und Ordner und keine einzelne „Datei“ wie z.B. dump oder tar erstellt.

[gabelhonz]

ja wie ??
du willst dein backup als einzelne datei haben ?? da gibts doch tausend möglichkeiten.
z.b machste nen kleines script was dir einfach je nach dem wann dein backup gemacht wird, halt kurz danach
deine Daten inne tar packt. das trägste dann in die crontab ein wie dein rdiff.
fertig, oder verstehe ich dich falsch ??

[409Coffemaker]

Ja klar, so kann man das machen. Ich wollte mich auch nicht beschweren.

Das ultimative Backuptool stelle ich mir so vor, dass ich via Cron ein Script starte, das dann ein komplettes Image der Festplatte in einer einzelnen Datei anfertigt (wie dump) und dann per SSH direkt auf einen Archivserver piped.
Dump ist da halt schon ideal… aber wie gesagt… laut Torvalds „not reliable“.
Wie sieht es denn mit tar aus? Das ist zwar verläßlich… aber erstellt es auch ein Image? Eher nicht, oder?

Ich bin ganz schön verwirrt… es gibt haufenweise Möglichkeiten.
Bandbreite/Dateigröße ist beim Backup egal… ich habe im RZ mehrere Server in einem Rack… die können untereinander schnell mal was austauschen.
Nach hause habe ich 6MBIT… von daher kann ich da auch mal eben 3-4GB nachts durchs Netz jagen.

Wichtig ist nur, das ich folgendes machen kann:

1.) Produktivserver HDD raucht ab. Dann übernimmt der Fallover Server den Betrieb.
2.) Ich fahre ins RZ, baue eine neue HDD ein und kann dann „onclick“ 1:1 den letzten Stand des Backups zurückspielen, ohne noch irgendetwas anpassen zu müssen. Selbst, wenn die Platte andere Spezifikationen hat, als die, die abgeraucht war.


Yves

[gabelhonz]

Moin

Also ich würde das so machen. Ich würde von meinem Server mit dd ein Image machen und dieses dann auf den Backup Server sichern.
Dann würde ich zusätzlich die wichtigsten Verzeichnisse mit rsync sichern ! /etc /boot etc... je nach dem was du halt damit machst!

Im Falle eines Totalausfalls würde ich ne neue Platte einbauen, mein Image mit dd zurückspielen und dann rsync drüber laufen lassen.

Ich würde niemals was mit tar oder cp sichern. Das ist viel zu unsicher.
Bei rsync hast du den Vorteil wenn du einmal deine Verzeichnissstruktur gesichert hast, dann später nur noch die Daten übeschrieben werden, die auch nur verändert worden sind. Zur sicherheit kannst du diese dann nochmal extra sichern.
Das kann kein tar oder cp. Das heißt du hast von jeder veränderten Datei im Backup ein Exemplar. Muss man nicht aber kann man.
Es gibt verschieden Lösungen, rdiff-backup macht das bestimmt auch so, wenn es auf rsync aufbaut.

Also ich kann rsync nur empfehlen, man kann sich auf jeden Fall drauf verlassen.

Und nu Mahlzeit

[ZX-81]

rdiff-backup hat noch den Vorteil, wenn ich eine Datei heute lösche und in 3 Wochen feststelle, dass ich sie noch gebraucht hätte, dann kann ich sie aus dem Backup holen.

@409Coffemaker: Freut mich, dass Dir rdiff-backup zusagt, kam mir fast so vor, wie wenn ich bisher der einzige Anwender im deutschsprachigen Forum gewesen wäre.

@gabelhonz: Was macht rsync eigentlich wenn sich die Quelldatei während des Kopiervorgangs ändert (z.B. Datenbankdatei)?


In Backup mit rdiff-backup gibt es noch weitere Infos dazu.

[gabelhonz]

rdiff-backup hat noch den Vorteil, wenn ich eine Datei heute lösche und in 3 Wochen feststelle, dass ich sie noch gebraucht hätte, dann kann ich sie aus dem Backup holen.

kann man mit rsync genauso machen.

Was macht rsync eigentlich wenn sich die Quelldatei während des Kopiervorgangs ändert (z.B. Datenbankdatei)?

hmm sry weis ich nicht. würde mich aber interessieren.

greetz

[ZX-81]

rdiff-backup hat noch den Vorteil, wenn ich eine Datei heute lösche und in 3 Wochen feststelle, dass ich sie noch gebraucht hätte, dann kann ich sie aus dem Backup holen.

kann man mit rsync genauso machen.

Vor zwei Jahren habe ich Scripts geschrieben, die ein versioniertes Backup mit rsync machen. Wenn man mit Hardlinks arbeitet belegen zumindest die unveränderten Teile keinen zusätzlichen Speicherplatz. Allerdings wurde das Ganze dann so komplex, dass ich nach etwas Fertigem gesucht habe. Dabei habe ich rdiff-backup gefunden.

Was macht rsync eigentlich wenn sich die Quelldatei während des Kopiervorgangs ändert (z.B. Datenbankdatei)?

hmm sry weis ich nicht. würde mich aber interessieren.

Das ist ein Problem aller derartigen Backups, rdiff-backup schreibt dann zumindest einen Fehler ins Log. Bisher konnte ich für solche Kandidaten immer eine Lösung finden, was Generelles wäre mir allerdings lieber.

[Fauli]

Du könntest den Logical Volume Manager benutzen und damit einen Snapshot erstellen. Falls sich der Aufwand lohnt (oder keine Rolle spielt)...

[ZX-81]

Du könntest den Logical Volume Manager benutzen und damit einen Snapshot erstellen. Falls sich der Aufwand lohnt (oder keine Rolle spielt)...

Wenn das der Logical Volume Manager kann, könnte man damit wohl die optimale Lösung aufbauen. Für eine Datenbank im Dauerbetrieb z.B. muss man sich sonst eine Sonderlösung einfallen lassen. Also erstmal Danke für den Tip (LVM habe ich bisher ignoriert, aber wenn er sowas kann ...). Bzlg. Aufwand: So eine Aktion jede Nacht per Cron auszuführen sollte doch vertretbar sein.