Re: Umgang mit Dubletten

[Raphael Becker <rabe@xxxxxxxxx>]

On Thu, Aug 20, 2009 at 06:47:19PM +0200, Werner Holtfreter wrote:
> Also Softlinks! Aber wie? Vielleicht sollte man mehrfach benoetigte 
> Dateien grundsaetzlich in ein Verzeichnis "SHARED" auslagern, um 
> unbedachter Loeschung vorzubeugen?

Wie waere es mit folgender Idee:

Jede Datei, die als "schuetzenswert" gilt wird anhand ihres Contents
indexiert, dabei bieten sich  Hashverfahren wie md5 oder sha256 an.

Dateien bleiben grundsaetzlich da liegen, wo sie logisch hingehoeren, also
in eine wie-auch-immer thematische Verzeichnisstruktur, z.B.
im Homeverzeichnis.

Ein regelmaessig laufender Job durchsucht regelmaeÃ?ig alle relevanten
Dateien und speichert dabei je einen Datensatz

<hashwert>|<timestamp>|<timestamp>|/pfad/datei 

in einem Index ab, wobei die Timestamps den Zeitpunkt der Indexierung 
und den Timestamp der Datei selbst sind. Dieser Index wird z.B. taeglich 
erneuert und fortgeschrieben.

Ein zweiter Job ermittelt nun - pro filesystem - alle Dateien, die noch
nicht im Repository liegen. Das Repository besteht aus Dateien, die als
Dateiname nur den Wert der Checksumme des Dateiinhalts haben, sortiert
in eine Verzeichnishierachie basierend auf den ersten 3 Stellen des
Hashwertes.


Beispiel:

e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa819349a0cfae /home/rabe/UUGRN/Aufnahmeantrag_UUGRN.pdf

Das Basisverzeichnis dieses Repositorys sei ./.repo relativ zu jedem
Mointpoint, also zB /.repo /usr/.repo /home/.repo

Unterhalb sei das repo nach den ersten 3 Stellen der Checksummen
untergliedert, damit nicht zu viele Dateien in einem Verzeichnis liegen,
ueber den Daumen gepeilt sind (bei Gleichverteilung) 256 Files pro
Hierachieebene sinnvoll.

Virtuell sei angenommen, dass /a/bc/abcdef.... eine sinnvolle Verteilung
ergaebe, dann wuerde obige Datei als Hardlink unter 

./.repo/e/55/e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa819349a0cfae
zum liegen kommen 
(16*256 = 4096 Verzeichnisse * ca 256 "Dateien pro Verzeichnis" = ca 1Mio Dateien) 

Der Pruefjob wuerde nun also den aktuellen Index vergleichen mit dem
Inhalt des Repositorys und im Repository noch fehlende Checksummen durch
Hardlink auf (eine/die) entsprechende Datei "fixieren".

Ein vom Index vollkommen unabhaengiger Konsistenzcheck koennte 
regelmaessig das Repository durchlaufen und fuer alle dort hart 
verlinkten Dateien deren Content-Checksumme mit dem Dateiname 
vergleichen und somit modifizierte Dateien im Repository passend 
umbenennen oder verschieben.

Zudem braeuchte man fuer das Backup nur hinzugekommene Dateien im
Repository sichern.

Wird eine Datei zB aus dem Homeverzeichnis irrtuemlich geloescht oder
modifiziert, kann man anhand des aufgezeichneten Index den Hashwert
eines Dateinamens zu einem bestimmten Zeitpunkt (oder Zeitraum)
ermitteln und kann die fehlende Datei durch einfaches Kopieren aus dem
Repository wieder herstellen.

Abwandlung: Kommt es auf den Platz nicht an und/oder soll ein zentrales
Repository ueber Filesystem- oder Rechnergrenzen hinweg angelegt werden,
zB als "ewiges Archiv", kann anstelle der Hardlinks auch eine Kopie
angelegt werden. Anhand des Indexes wuerde man dann fehlende Dateien im
Repo nicht per Hardlink "sichern", sondern einfach als Kopie. Das haette
ausserdem den Effekt, dass das Repository nicht inkonsistent werden
*kann* weil die Dateien im Homeverzeichnis ja beim ueberschreiben das
Repository nicht direkt beeinflussen, der Pruefjob waere also obsolet.

Nebeneffekt: Zeichnet man die Checksummen der Dateien als Dateiname auf,
kann man beim Lesen (Recoverytest) des Backups auch unmittelbar pruefen,
dass die Daten im Backup fehlerfrei vom Medium gelesen werden koennen
bzw. beim Schreiben des Backups vollstaendig und fehlerfrei geschrieben
wurden.

Denkbar waere, fuer das Backup die einzelnen Dateien mit bzip2 zu packen
und entsprechend umzubenennen, etwa
e55d56d38035824cf1e2ead96e7688a72f3dac068d97e98d25fa819349a0cfae.bz2
Der Konsistenzcheck muesste hier allerdings die Dateien jeweils
entpacken, was natuerlich wesentlich CPU-intensiver ist.

Wichtig dafuer ist, dass man fuer die Wiederherstellung einer Datei aus
dem Backup den aufgezeichneten Index benoetigt. Denkbar waere, einen
(abgeschlossenen) Index selbst als Checksumme in das Repository zu
kopieren und das im (aktuellen) Index entsprechend festzuhalten.

Zusaetzlich koennte man diese "speziellen" Sicherungen des Indexes 
durch immutable-Flags ("chattr +r foo"  oder "chflags noschg foo") 
gegen Ueberschreiben, Loeschen etc zu schuetzen und zugleich als
Erkennungsmerkmal fuer "diese Datei enthaelt einen Index" zu verwenden.

Weitere Methoden zur Signierung oder Verschluesselung von Dateien im
Repository seien hier nur erwaehnt aber nicht weiter ausgefuehrt.

Zusammengefasst zielt das Ganze darauf ab, dass jede Form von Archiv
oder Sicherung auf eine thematische Sortierung verzichten sollte und
stattdessen streng anhand von eindeutigen Merkmalen wie Checksummen
operieren sollte, wenn moeglich *ausserhalb* der Umgebung, auf der
aktiv gearbeitet wird.

Nur eine Idee.

Achso, Thema Doubletten: Die Treten im Repo nicht auf, koennen aber im
Homeverzeichnis entstehen. Aber automatisch darf man sie nicht einfach
durch Hardlinks de-duplizieren wenn nicht sicher gestellt ist, dass die
Datei Read-Only ist, sonst aendert sich der Inhalt der Datei ungewollt
auch fuer andere Stellen (bei Hardlinks). 


Gruss
Raphael
-- 
Raphael Becker <rabe@xxxxxxxxx>                   http://rabe.uugrn.org/
                             https://www.xing.com/profile/Raphael_Becker
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..



--
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/