Inkrementelles Backup mit tar

martin

martin

Well-Known Member
Hallo

ich bin gerade dabei mir ein Backup Script für meinen Server zu basteln und stoße dabei auf ein kleines-, aber nicht unerhebliches, Problem. Ich möchte das Verzeichnis /usr/home/ wöchentlich komplett- und täglich inkrementell sichern. Soweit so gut, full-backup geht, aber irgendwie ignoriert mir das Script die --newer option.
Hier mal mein Versuch:

tar --newer "2011-01-31" -czf test.tar.gz /usr/home/
Zum Vergrößern anklicken....

wie gesagt, es wird immer alles getart, ich hätte aber gerne nur die Änderungen seit dem 31.01. Wenn ich das Ganze mit dem Verzeichnis /etc/ an Stelle von /usr/home/ versuche, scheint es zu klappen, ich weiß aber nicht woran es liegen könnte...:confused:

Gruß
martin
 
ich hab mal kurz einen blick in die manpage geworfen.
anscheinend guckt der dabei auf die ctime.

es gibt auch noch newer-mtime, newer-than und newer-mtime-than.

und -u.

diese parameter moechtest du vielleiciht mal angucken.
 
Ich bearbeite das immer mit 'find' ...
Code: 
/usr/bin/find /usr/home -mtime -1 -type f -print | /bin/pax -w -z -f /spinpoint/Backup/Daily/${datum}.tar.gz
Das läuft dann zweimal am Tag.
 
Zuletzt bearbeitet:
Müsst ihr euch immer so etwas antun?

dump macht solche Sachen wie Assoziation von Backup-Level ohne Fummeleien automatisch. Wenn es ZFS sein soll, dann kann man zfs send -i benutzen.
 
Und da beide auf Blockebene arbeiten, sind sie gerade bei großen Mengen kleiner Dateien wesentlich schneller.
 
Also es geht auch wesentlich einfacher: rsync! wenn man verzeichnisse effizient spiegeln möchte.
Ansonten kann ich auch dump wärmstens empfehlen.
 
Also zunächst mal danke an dettus, mit --newer-mtime hat es zwar nicht hingehauen, aber mit --newer-mtime-than. Soweit so gut, jetzt läuft das Backup so wie ich es mir vorgestellt habe.

Ich nehme tar, weil rsync eben "nur" spiegelt, ich aber gerne auch auf ältere Datenbestände Zugriff haben möchte, falls mal jemand versehntlich was löscht.

Mit dump habe ich mich nie groß bechäftigt, da ich bis jetzt immer der Meinung war, dass man lediglich gesamte Slices dumpen kann und somit auch nur gesamte Dumps restoren kann (also nicht einzelne Dateien). Eigentlich fahre ich ganz gut mit tar, aber man ist ja immer offen für Neues, also werd ich mir das dump mal näher anschauen.
 
vielleicht verstehe ich das nicht, was ihr mit "spiegeln" meint, aber rsync ist ziemlich flexibel und sollte das Problem easy in den Griff bekommen. Zudem nimmt es ab dem ersten Lauf die "Deltas" und wird deshalb in der Folge recht flott.
In Default löscht rsync nicht überzählige (veraltete) Dateien im Ziel (und auch nicht von der Quelle), es kann aber diese Option(en) aber durchaus auch.
Es kann außerdem bestimmte Verzeichnisse auslassen oder sich nur um bestimmte kümmern. Das ist sehr sinnvoll, weil es ansonsten mountpoints mit gemountetem Inhalt überträgt, was nicht immer gewünscht ist.
Es kann nicht (wenn ich das recht erinnere) über Partitionsgrenzen hinweg syncen.

In meinen Augen ein wirklich zu unrecht viel zu sehr vernachlässigtes Tool, das ich als komfortables und schnelles cp sehr gerne nutze und nicht etwa "nur" im Server-Client Modell.
 
restore(1) kann auf jedes Dateisystem wiederherstellen. Die per "zfs send" erstellten Dumps können allerdings nur auf ZFS wiederhergestellt werden. Ist vielleicht gut das im Vorfeld zu wissen. :)
 
Noch eine Nebeninfo, weil viele Leute wegen dump irgendwelche Illusionen haben:

dump hat nichts mit dem stupiden dd zu tun!

Und noch eine Nebeninfo zur Nebeninfo:

dd ist ein Scheiß Ersatz für dump.

Btw... schade, dass zfs kein richtiges dump anbietet. Jedes vernünftige Dateisystem sollte das anbieten.
 
Mag vielleicht ein Overkill sein, aber wenn es um längerfristige Backups geht, kann ich bacula empfehlen. Sorry für alle Shell-Bastler, aber ich verlasse mich bei so was lieber auf ein ausgereiftes Backup-System :)

check: http://www.bacula.org
ports: /usr/ports/sysutils/bacula

Bacula basiert auf einem Client/Server-Prinzip, ist ein wenig Aufwand das einzurichten, aber ist dann ein fire-and-forget-System. Hat grade Stärken bei Szenarien beim Scheduling, wie 1xmonatlich full Backup, täglich inkrementell, 2 wöchentlich differentiell (=diff zum letzten full), Kompression, Erweiterbarkeit usw.

Wie gesagt, weiss nicht, ob so was wie bacula schon zu "groß" angesetzt ist, aber tut privat wie im Firmenumfeld hervorragende Dienste. Eventuell einen Blick wert, wenn es auch um ne Historie von Backups geht..
 
Das ist natürlich zu erwägen. Ich hatte schlechte Erfahrungen mit amanda. Das kommt mir sehr frickelig vor und Backup sollte immer anständig und felsenfest überzeugen.

Für dump brauchst du eigentlich kein Shellskript. Ich habe nur eines, was mir erlaubt, meine crontab etwas zu stauchen (weil jeder Wochentag ein anderes Level bei mir hat) und das läuft durch einige Pipes und wäre unübersichtlich.

Im Endeffekt habe ich auch (wird in der crontab festgelegt):
  • am 1. des Monats ein Level 0 Backup
  • am 8.,15.,22.,29. ein Level 1
  • an anderen Tagen die Levels so zerstreut, damit ich nicht zu viele Backups brauche, um zu restaurieren
 
bin auch für dump!

bei "zfs send" sollte man an der empfängerseite immer ein "zfs receive" benutzen und nicht den rohen datenstrom als "backup" benutzen...
Um Fragen vorzubeugen, hier noch ein Link mit der Erklärung, warum:

http://www.solarisinternals.com/wik...ZFS_Snapshot_Streams_.28zfs_send.2Freceive.29

Auf der selben Seite steht auch: "Currently, ZFS doesn't provide a comprehensive backup/restore utility like ufsdump and ufsrestore commands. However, you can use the zfs send and zfs receive commands to capture ZFS data streams. You can also use the ufsrestore command to restore UFS data into a ZFS file system."
 
Was an dump saugt ist schlicht die schlechte Verifikationsmöglichkeit.
Zudem ists recht knifflig damit ne Failoverplatte vorrätig zu haben, also eine Art Replikation für Arme.
Deshalb hab ich bei mir Dump und rsync parallel laufen. Auf den Systempartitionen der Failoverplatten werden einmal monatlich Level 0 Dumps via restore entpackt. Bei nem Failover muss ich dann nur noch die höheren Level zurückbraten, was ziemlich schnell geht. home wird via rsync auf die Failoverplatten gebracht.

Das schöne an nem guten Backupsystem ist, dass alles durch die hohe Belastung wesendlich schneller den Geist aufgibt, als ohne Backups. :ugly:
 
Kein Tool kann alles :) Die intelligente Kombination aus mehreren macht es aus!
Aber eine Art Cheksummme mit DUMP wäre wirklich toll. Gibts da nich was?
 
Backup ist keine Failover-Lösung. Wenn man nicht bereit ist zu warten, wenn die Platte total abraucht, dann sollte man mit Redundanz kontern (aka RAID!=0).

Es geht um die Datenunfälle, die teuer sind. Daten, die nicht wieder rekonstruierbar sind. "Falsches rm" oder ein Brand, Flut, Atombombe... in diesen Fällen kann man ruhig etwas warten, bis die Daten vom Backup wieder da sind (Hauptsache sie sind überhaupt da!).
 
Backup ist nunmal ein Konzept. z.B.
- System läuft auf mit raid1 auf x-Platten (mind zwei)
- Von wichtigsten Verzeichneissen gibt es ein tägliches rsync
- Danach erfolgt ein Dump des Systems auf eine externe Festplatte die rotiert.
- Die rotierte Festplatte lagert außerhalb des Räumlichkeiten.

Damit hat man ein desaster recover UND eine Historie der Dateien falls mal was gelöscht wird.

Beliebig erweiterbar. Es ist ein Konzept. Kein Rezept :)
 
nakal schrieb:
Backup ist keine Failover-Lösung. Wenn man nicht bereit ist zu warten, wenn die Platte total abraucht, dann sollte man mit Redundanz kontern (aka RAID!=0).
Zum Vergrößern anklicken....

Doch, da widerspreche ich. Die Bereiche greifen ineinander. Ich habs ja Neujahr gehabt, dass bei einem Raid10 die zwei entscheidenden Platten nacheinander ausfielen - die Zweite beim Rebuild.
Ich hab das von dir geschriebene schon oft so gehört und ich stimme nicht zu. Die Ausfallzeit kostet immer das Selbe. Egal, ob davor ne Woche Pause wegen Weltuntergang war, oder nicht. Die Zeit ein Backup einzuspielen kostet das Selbe.
Umgekehrt stimme ich allerdings voll zu - eine Failoverlösung ersetzt kein Backup.

Die Art Failoverlösung, die ich da beschreibe ist auch in dem Sinne kein direktes Failover, bei dems mal kurz ruckelt, wenns passiert. Es ist ein Backup, was fertig eingespielt auf Datenträger vorgehalten wird, weil es im Falle eines Crashs aufs Tempo ankommt. Es ist im Gegensatz zu Ausfallsicherheit - dazu zähle ich Raid > 0 mit Datenverlust behaftet.
 
Sorry Leute, aber jetzt muss ich nochmal das ursprüngliche Problem rauskramen. Anscheinend klappt das doch nicht so wie es zunächst geglaubt habe. Und zwar mit keiner der von Dettus genannten Optionen. mit --newer-mtime-date wird zwar nicht mehr alles getart, im Gegensatz dazu aber nichts mehr, das heißt ich bekomme immer eine Datei mit der Größe von 45byte. Hier mal mein letzter Versuch:

tar --newer-mtime-than /root/Backup/full-date -czf /tmp/Backup/04_02_2011.tar.gz /usr/jails/www/
Zum Vergrößern anklicken....

Die Datei /root/Backup/full-date hat als Inhalt "2011-02-01" und ls-al gibt als Datum dieser Datei ebenfalls den 1. Februar 2011 an. :confused:
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben