Hard-Link-Backups

Du hast eine Idee für ein Projekt?
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

jens hat geschrieben:Ich könnte nun in der Datenbank die Link Anzahl mit führen und dann auf einer weiteren Kopie der Datei zurück greifen...
Dann muß ich allerdings die Limits der Dateisysteme kennen. Oder ich sagt generell max. 1024 sind erlaubt. Dürfte ja nicht all zu oft vorkommen.

Bessere Ideen?
Fehler fangen und anstatt einen Hardlink anzulegen die Datei kopieren, dann reichts wieder für neue 1204 Backups.
the more they change the more they stay the same
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Gute Idee... Hab mal versucht das umzusetzten, mit: https://github.com/jedie/PyHardLinkBack ... 50dea1a6a5

Aber muß ich noch genauer Testen. Außerdem ist damit das hin und her umbenennen doof. Aber das braucht mehr Zeit für eine bessere Lösung...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

So, hab einen unittest gebaut, der das NTFS 1024 hardlink Problem testet: https://github.com/jedie/PyHardLinkBack ... 615de7b356

Ist natürlich ein wenig Resourcen verschwendend :P

Ich habe es in zwei Phasen unterteilt:

1. 1022 Dateien werden mit gleichen Inhalt erzeugt und ein Backup davon gemacht
2. Es werden 4 weitere Dateien "A", "B", "C" und "D" erzeugt, mit ebenfalls gleichem Inhalt und davon dann ein Backup gemacht...

Anhand der Error Log kann man sehen was passiert:
Can't link 'BAK2/foo A.ext' to 'BAK2/foo C.ext'
Can't link 'BAK2/foo B.ext' to 'BAK2/foo C.ext'
Can't link 'BAK1/file 0001.txt' to 'BAK2/foo C.ext'
...
Can't link 'BAK1/file 1020.txt' to 'BAK2/foo C.ext'
Can't link 'BAK1/file 1021.txt' to 'BAK2/foo C.ext'
Can't link 'BAK1/file 1022.txt' to 'BAK2/foo C.ext'
Dabei steht "BAK1/" die das Verzeichniss des ersten Backup laufs und BAK2/" für den zweiten...

Man kann sehen, das für "A" und "B" noch hardlinks erzeugt werden können. Dann sind es halt die 1024...
Für "C" wird dann ein links "gesucht"... Natürlich ein wenig doof: Ich probiere einfach solange, bis ich einen Link machen kann. Aber nur einmal! In der Datenbank werden nicht nutzbare Dateien markiert... Somit dauert das ganze nur einmalig 1024 Versuche :P

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

So: Neues Release v0.6.0

Nun sind folge Backups um einiges schneller, gerade wenn es viele Daten sind und sich wenig geändert hat:

Jetzt wird das letzte komplette Backup herrangezogen: Alle alten Dateien werden nur noch per Änderungsdatum und Dateigröße vergleichen. Sind diese gleich, wird direkt ein Hardlink erzeugt. Wenn Unterschiedlich dann der Inhalt verglichen...

Generell wird das Backup sortiert nach Dateidatum gemacht: Von der neusten Datei zur ältesten.

Also: Bei einem zweiten Backup lauf passiert folgendes:

* Dateidatum der neusten Datei aus dem letzten Backup raussuchen. Nennen wird es mal Dateidatum-X.
* Alle Dateien die neuer als Dateidatum-X sind, werden generell über den Inhalt unterschieden.
* Ältere Dateien als Dateidatum-X, werden im alten Backup mit selben Pfad + selbe Dateigröße + selbe Änderungsdatum gesucht und direkt als Hardlink übernommen.


Damit wird es nun auch Praktisch nutzbar :D


Aber es gibt noch einiges zu tun, siehe: https://github.com/jedie/PyHardLinkBackup/issues

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Ich frage mich gerade, ab welcher Dateigröße es wohl überhaupt Sinn macht einen Hardlink zu nutzen...

Zumindest bei 0-Bytes Dateien ist es vermutlich kontraproduktiv.

Und ich meine, das mache Dateisysteme sehr kleine Dateien auch direkt im 'MFT' speichern.
Bei NTFS z.B. werden alle Dateien die kleiner als 1KB direkt im MFT gespeichert, siehe: http://blogs.technet.com/b/askcore/arch ... rowth.aspx

ext4 speichert wohl kleinere Dateien direkt im inode, siehe: https://ext4.wiki.kernel.org/index.php/ ... nline_Data

Keine Ahnung wie viel ein Hardlink demgegenüber verbrauchen würde...

Hinzu kommt, das jeder Datei Eintrag in der SQLite Datenbank von PyHardLinkBackup ja Speicher verbraucht. Nicht viel, aber ein paar Bytes ja schon.
Mal so grob Kalkuliert: Hab 41.032 Dateien im Backup, die SQLite Datei ist 12.064.768 Bytes groß, also: ~300Bytes pro Eintrag.

Noch ein Punkt: Viele kleine Dateien verlangsamen auch den Backup Prozess, auf verschiedene Weise...

Wo also die Grenze ziehen?!? Bei 1024 Bytes, wegen NTFS?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

So, gibt nun v0.7.0 und neu: Man kann alte Backups auch überprüfen: https://github.com/jedie/PyHardLinkBack ... ing-backup
$ phlb verify --fast ~/PyHardLinkBackups/documents/2016-01-07-102310
Mit --fast wird der eigentliche Dateiinhalt nicht geprüft, ohne --fast wird der Hast nochmal vom aktuellen Dateiinhalt berechnet und verglichen.

Ansonsten wird immer geprüft:
  • ist Datei überhaupt noch im Backup vorhanden
  • Datei größe
  • Hash in der Hash-Datei
  • stat.st_mtime

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Hab heute eine für mich wichtige Funktion mit v0.8.0 implementiert:

Code: Alles auswählen

$ phlb add
-> https://github.com/jedie/PyHardLinkBack ... o-database

Damit kann man manuell einen Dateibaum ins Backup aufnehmen und deduplizieren lassen.

Für mein Szenario: Ich hatte meine Daten auf dem Lokalen Rechner. Von da hab ich sie auf ein Netz-Laufwerk kopiert und nutzte sie von nun immer von dort aus.
Die Lokale Kopie hätte ich gern im Backup. Aber 1TB wieder neu kopieren um den Ursprung wieder zu löschen?

Also die Dateibaum einfach manuell in das normale Backup-Verzeichnis verschieben und phlb add ausführen. Fertig.

Gut, ist jetzt schon was, was man nicht wirklich oft braucht. Aber so kann man auch die Datenbank komplett neu aufbauen lassen: Einfach SQLite Datei löschen und phlb add ausführen und warten...


Alles natürlich mit tests ;)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Werd heute abend in Köln auf der http://wiki.pythonde.pysv.org/pycologne/ von PHLB erzählen... Geplant ist das selbe am 27.4. in Düsseldorf: http://www.pyddf.de/


Gerade hab ich folgende Ausgaben mit chkdsk unter Windows:
...
Indexeinträge, die auf Datei 226320 verweisen, werden nicht überprüft,
da die Datei zu viele Dateinamen enthält.
Indexeinträge, die auf Datei 305711 verweisen, werden nicht überprüft,
da die Datei zu viele Dateinamen enthält.
Indexeinträge, die auf Datei 409991 verweisen, werden nicht überprüft,
da die Datei zu viele Dateinamen enthält.
Indexeinträge, die auf Datei 726616 verweisen, werden nicht überprüft,
da die Datei zu viele Dateinamen enthält.
...
Dateisystem wurde überprüft, keine Probleme festgestellt.
Keine weiteren Aktionen erforderlich.
...
Hm... Ob das mit den hardlinks zusammen hängt?!?

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

jens hat geschrieben:Geplant ist das selbe am 27.4. in Düsseldorf: http://www.pyddf.de/
Das ist morgen und findet statt ;)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten