GerBra
Hoppa,
ich arbeite gerade an einer Backup-Lösung, für die per rsync diverse Clients
ihre zu sichernden Daten auf einen Backup-Server schieben.
Um Platz auf dem Backup-Server und im extern zu sichernden Archiv zu sparen,
läuft vor dem Backup auf das externe Backup-Gerät ein Script, welches intensiv
Gebrauch von Hardlinks macht. Also identische Dateien unlinkt und diese per
Hardlink mit einer realen Datei verlinkt.
Im Idealfall brauchen so z.B. 10 Clients mir ArchLinux nur den Platz von einem.
Jetzt ist es aber so, daß andere Distributionen oftmals die "gleichen" Dateien haben.
Z.B. ist die md5sum von (Debian) /bin/fgrep die gleiche wie bei (Arch) /bin/fgrep,
da die beiden Dateien sich vom Inhalt nicht unterscheiden.
Diese würden logischerweise hart verlinkt.
Jetzt nur das "Schönheitsproblem" (oder evtl. ein Admin-Problem?):
Durch das Linken erhält z.B. das /bin/fgrep der Arch-Linux-Clients die mtime
des fgrep vom Debian-System, aus z.B. 2007-05-27 15:24:27 wird dann
2006-10-10 07:51:09.
Beim Rücksichern aus dem Backup bekommt das Arch-fgrep dann natürlich
auch diese mtime.
Und da meine Frage: Würdet ihr sowas als "Schönheitsfehler" (besser das Backup
ist wieder da als ein dämliches Datum) oder doch als Sicherheits/Admin-Problem
einordnen? Prüf(summen)-Tools wie aide,tripwire bekommen mit diesen "modifizierten"
Dateien sicher Schluckauf. Würdet ihr das als tolerierbar bezeichenen oder wäre
euch unwohl?
Ich könnte bei der Entscheidung, ob im Script nun hartgelinkt wird, sicher auch noch
die mtime als Kriterium hernehmen. Dann würde ich mir IMHO aber einige
Möglichkeiten des Verlinkens verschenken (z.B. selbst bei Clients der gleichen Distri,
aber mit evtl. unterschiedlichen Versionsständen, würde dann z.B. die /bin/fgrep
nicht verlinkt werden.)
Wäre es also eurer Meinung nach OK, daß nach einem Restore manche Dateien eine
andere mtime als das "Original" haben?