[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backupstrategie
[Thread Prev] | [Thread Next]
- Subject: Re: Backupstrategie
- From: Markus Hochholdinger <Markus@xxxxxxxxxxxxxxxxx>
- Date: Tue, 3 Jun 2008 10:32:57 +0200
- To: uugrn@xxxxxxxxxxxxxxx
Hallo, Am Dienstag, 3. Juni 2008 01:19 schrieb Werner Holtfreter: > Am Freitag, 30. Mai 2008 13:24:11 schrieb Markus Hochholdinger: > > > Wuerdest du das Script zur Verfuegung stellen? > > Ja, das mache ich gerne, > danke fuer die Muehe, allerdings ist es fuer mich als Gelegenheits- > programmierer viel zu komplex, um auch nur den Kern zu verstehen. und meine Scripte sind dazu auch noch sehr speziell auf meine Beduerfnisse zugeschnitten. > Ich habe aber inzwischen entdeckt, dass sowohl in > http://linuxwiki.de/rsync/SnapshotBackups > als auch in der Originalquelle > http://www.mikerubel.org/computers/rsync_snapshots/ > deine Verbesserungen schon beschrieben und vor allem die Anwendung > der rsync-Option erklaert wird. (Aus der Manpage bin ich nicht > schlau geworden.) Ich hatte mir es damals aus der Manpage erarbeitet. > In der Originalquelle findet sich aber im Abschnitt "Putting it all > together" eine Warnung, beide Beschleunigungsmassnahmen (--link-dest > und Verzicht auf rm) gleichzeitig zu verwenden, weil dadurch der > Speicheraufwand erheblich steigt. > Ich habe es getestet, und konnte das Problem reproduzieren, auch > wenn ich es zunaechst gar nicht gesehen habe! rsync ersetzt eine > Datei, die einmal geaendert wurde, nicht mehr durch einen Hardlink > in backup.0, wenn dort schon eine gleiche Datei steht! Die Folge > ist, dass die History die betreffende Datei mehrfach enthaelt, statt > nur Hardlinks der Datei. Je tiefer das History reicht, desto > nachteiliger ist das Verhalten, ist sie flach (nur wenige Ebenen) > faellt es nicht auf. > Ist backup.0 dagegen jedesmal leer, dann wird bei jedem Durchlauf je > ein Inode der Datei durch einen Hardlink ersetzt. Hm, das ist mir neu und werde das auch mal ueberpruefen. Fuer mich bedeutet das, dass ich einen Kompromis zwischen Laufzeit und verbrauchten Festplattenspeicher machen muss. Eine Option waere evtl. ein "cp -alu" vom neuesten Backup zum aeltesten Backup zu machen und danach erst das aelteste Backup als Ziel fuer ein neues Backup zu nehmen. Das muss ich aber erstmal ausprobieren ob das schnell genug ist. Ein "cp -alu" muss ja trotzdem ziemlich viel lesen aber nicht viel schrieben (wegen -u). -- Gruss \|/ eMHa (o o) ------------------------------------------------------oOO--U--OOo-- Markus Hochholdinger e-mail mailto:Markus@xxxxxxxxxxxxxxxxx .oooO www http://www.hochholdinger.net ( ) Oooo. ------------------------------------------------------\ (----( )- \_) ) / (_/ -- http://mailman.uugrn.org/mailman/listinfo/uugrn Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste Archiv: http://lists.uugrn.org/