Backup Solution

[lewold]

Ich arbeite in einem Heimbuero - mein file server ist Linux (suse 8.0)
Da man aus Dummheit klug wird mache ich auch regelmaessige backups - nur bin ich mit meiner Loesung irgendwie unzufrieden:

Die Datenmengen sind teilweise schon ziemlich gross - sagen wir einmal 10GB pro alias, wobei ich etwa 7 aliases sichern muss. (70GB total daumen mal pi).

Tapes sind mir zuwieder - deshalb sichere ich auf einen 2. PC. Dies ist ebenfalls ein Linux hobel.
Die Sicherung lauft momentan einfach ueber ein rekursives copy, was natuerlich nicht gerade das gelbe vom ei ist. (Geloeschte Dateien werden auf der Sicherung nicht geloescht, probleme mit file rechten, etc etc).

Zuerst einmal eine generelle Frage. Gibt es eine art "Standard Utility" welche man in so einem scenario grundsaetzlich einsetzt? Ich habe halt nichts wirklich passendes gefunden, aber da ich kein Linux profi bin heisst das gar nichts.

Detailfragen:
Q1) Ich will ab jetzt (ueber crontab besteuert) shell scripts aufrufen welche mir die einzelnen aliases TARen. Die Tars stelle ich in ein "backup" directory vom fileserver. Die backup maschine holt sich nurmehr die tars ab.
Q1a) Hat TAR probleme mit so grossen datenmengen ?
Q1b) Gibt es eine Moeglichkeit bei einem recursiven TAR auch zu kompressen? Wenn ich nicht falsch liege vertragt sich compress und recurse nicht, waere aber irgendwie huebsch.
Q1c) If not Q1b) Then "gibts eine andere standard utility welche das kann?"

Q2) Ich will dass die backup maschine automatisch hochfaehrt (geht ueber bios) - das "backup abholen script" durchfuehrt, und dann wieder herunterfaehrt (shutdown 0 oder so).
Q2a) Geht das im generellen
Q2b) Wie setzt man das auf, ohne dass die maschine bei normaler anwendung das script aufruft (will ja nicht jedes mal ein automatisiertes shutdown wenn ich den hobel aufdrehe).


Okis - solltet ihr hierzu irgenwelche tips haben dann mal danke im voraus.

Chris Lewold

[MANX]

Hi!

Ich versuch's mal mit ein paar Anregungen:
Eine Frage: Welche Linux-Distribution?

ad Q1*)
Du könntest Dir rsync anschauen, da hier nicht alle Daten sondern nur die Unterschiede synchronisiert werden.
http://samba.anu.edu.au/rsync/features.html

ad Q2*)
Über das Problem hab ich mir auch schon den Kopf zerbrochen (v.a Q2b).
Möglicherweise könnte man das Runlevel 4 dafür missbrauchen, da es normalerweise nicht verwendet wird: Sprich zu startendes Script ins rc4.d verlinken.
Standarmäßig bis in Runlevel 3 booten. Bei Bedarf ein Level höherschalten, oder gleich bei LILO eine Option machen, wenn' geht.

Grüße

Manx

[MANX]

... am LILO-Prompt funktioniert's mit "Linux 4" um ins Runlevel 4 zu booten (möglicherweise die inittab anpassen).

Grüße

Manx

[Belgarath]

Hi Chris!

Zu Q1: in dieser 'Backup-Sammlung' für Linux auf GDS gibt es etliche scripts, die neben 'full' auch 'incremental backups' beherrschen. Ich setze auf dem File/Plotter-Server im Büro meines Vaters backup-1.03 von Karel Kubat ein, wobei ich statt afio tar verwende ... und dabei kann man natürlich auch komprimieren. Über crontab (oder ähnliches, weiß ich jetzt nicht so genau, das System läuft jetzt schon über ein Jahr praktisch unverändert ) wird jeden Monatsanfang ein Komplettbackup gezogen, jeden Tag ein incrementelles Backup (im Verhältnis zum letzten Backup). Gesichert wird das Ganze auf CD-ROMs (incrementell auf einer CD-RW), das Brennen des Komplettbackups wird über Custom-Commands in Webmin gesteuert, die Benachrichtigung der dafür verantwortlichen User erfolgt über mail ...

lg
Klaus

edit: Einzelfile-Restores sind ebenfalls über die Custom-Commands im Webmin möglich ...

[Pavlovs_Dog]

Hallo!

Ich würde an Deiner Stelle so vorgehen, daß der Sicherungsserver nicht tar-files abholt, sondern die zu sichernden Filesysteme mountet und dann lokal seine Tarfiles erstellt.
Ich würde diese auch nicht komprimieren, denn auf dem Sicherungsserver solltest du ohnehin so viel Platz haben, daß die tarfiles wieder entpackt werden können.
Du ersparst dir damit eine 2. Abhängigkeit bei der Fehlersuche falls mal etwas nicht klappt und du ersparst dir vor allem reichlich Platz auf der zu sichernden Maschine da auf dieser ja keine tarfiles angelegt werden müssen.
Tar kann auch mit sehr großen Datenmengen umgehen und übernimmt auch permissions und ownership der einzlenen Files.
Ich würde das Sichern nicht an einen Init-Level binden, sondern am Sicherungsserver einen Eintrag in der crontab machen.
Du bootest den Rechner um 01:00h und um 01:30h geht der crontjob los.
In diesem Job wird gemountet (NFS), getart, unmonted und runtergefahren.

Gruß
PD

[Belgarath]

Na ja, bei bis zu 70 GB ist mounten über NFS und tar auf der Sicherungsmaschine auf die gemounteten Verzeichnisse vielleicht suboptimal

NFS hat ziemlich viel Protokoll-overhead (ftp geht deutlichst! schneller), und je weniger Daten ich tatsächlich über das Kabel bringen muß (gzip'ed ist das Ganze nun mal kleiner), desto besser (v.a. schneller) ...

Wenn schon, dann über ftp (was, wie gesagt, schneller ist, aber mit den Berechtigungen schaut's dann nicht wirklich gut aus), besser noch (im Sinne von performanter) auf dem eigentlichen Server tar und gzip laufen lassen (respektive tar mit entsprechender Komprimierung einsetzen) ... und inkrementelles Sichern ist dann eine weitere heftige Ersparnis ... am Backup-Rechner kann man ja dann durchaus wieder den aktuellen Stand der Verzeichnisse aus den tar-Files aufbauen ...

lg
Klaus

[Pavlovs_Dog]

Hallo Klaus!

Wenn du die Zeitspannen für das lokale Aufbauen der tarfiles noch in die Rechnung miteinbeziehst, gehe ich jede Wette ein daß die NFS-Lösung schneller ist.

Aber man könnte es ja auch so machen:

linux-save# ssh linux-work "tar cz - /myfiles" | tar -x - /mybackup/mytar.tar.gz

Via ssh (oder rsh) startest einen tar auf der Quellmaschine welcher auf Standard-Output aber gezippt, tar't und liest diesen als Standard-Input auf dem Backup-Rechner wieder ein.

Dann ersparts dir das mounten und NFS, hast ein gezipptes tarfile und dennoch am Arbeitsrechner kein tarfile aufbauen müssen.

PS: Die Befehlszeile ist nicht getestet, aber in der Form bei schon eingesetzt worden.

lg
PD

[Belgarath]

Bezüglich Tempo: hängt von mehreren Faktoren ab (wie 'potent' ist der Server, wie hoch ist die Auslastung durch andere Prozesse zum Zeitpunkt der Sicherung, wie sind die Datenfiles beschaffen, ...), aber ob er tar nun auf dem Server durchführt (der vermutlich durchläuft) oder auf dem Backup-Rechner (der sich nach der Abholaktion ja wieder ausschalten soll) ist für die Laufzeit des tar und des gzip wurscht (vergleichbar schnelle Rechner vorausgesetzt) - nicht wurscht ist es eben, ob ich nun 70 GB oder (im Falle von primär Textdateien als Daten) vielleicht nur 20 GB übertrage ...

Die Variante über rsh/ssh sieht übrigens sehr schön aus ...

Trotzdem würde ich eher zu einer Variante mit inkrementellem Backup raten -> Laufzeit und Platz-/Bandbreitenbedarf verringern sich enorm!

lg
Klaus

[Pavlovs_Dog]

Rehi Klaus!

Die Sache mit dem Tempo ist bei Sicherungsjobos ohnehin fast nie ein Faktor.
Ich denke daß so ziemlich jeder in den Nachstunden sichert und der Zeitraum von 02:00h - bis 05:00h ein fast überall geschützter Bereich ist.

Drum meine ich, daß es "wurscht" ist welche Methode man anwendet - solange es keine 24/7 Umgebung ist.

Aber eines ist mir aufgefallen:
Die Leute "stehen" so darauf, daß gelöschte Files auch in den Backup-Ständen gelöscht sein sollen.
Ich glaube die verwechseln hier "rsync" (spiegeln) mit backup.
Ich verwende sehr oft meine Sicherungsarchive um gerade gelöschte Files wiederherzustellen.
Ich mache das so, daß ich immer 7 Stände (je Wochentag einer) habe, die sich eben nach 7 Tagen jeweils überschreiben.
d.h. der Output von 'date +%w` ist Teil meines tarfilenamens.

Und zum Thema "inkrementelles Backup" kann ich nur sagen, daß dies im Falle einer DB-Umgebung nichts bringt.
Da sicherst 4% Daten die ohnehin nicht "sensibel" sind, und die restlichen 96% liegen in nur EINEM Verbund von Extent-Files wo ein inkrement ja nichts bringt.
Aber das soll nichts bedeuten, ist blos bei meinen Kunden eine solche Umgebung - bei anderen mag dies ganz anders aussehen.

So - und jetzt geh ich Kuchen backen ;-)

LG
PD

[_m3]

Kauf dir dir Arkeia Proofessional, weil:

Does Arkeia back up to a hard disk (Professional version)?

Only the professional version of Arkeia can back up to a hard disk.
You have to configure FILE tape, drive and library for that.

Damit sollten alle Ansprüche befriedigt werden