Fehler fangen und anstatt einen Hardlink anzulegen die Datei kopieren, dann reichts wieder für neue 1204 Backups.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?
Hard-Link-Backups
the more they change the more they stay the same
- 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...
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...
- 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
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:
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
Ist natürlich ein wenig Resourcen verschwendend
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:
Dabei steht "BAK1/" die das Verzeichniss des ersten Backup laufs und BAK2/" für den zweiten...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'
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
- 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
Aber es gibt noch einiges zu tun, siehe: https://github.com/jedie/PyHardLinkBackup/issues
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
Aber es gibt noch einiges zu tun, siehe: https://github.com/jedie/PyHardLinkBackup/issues
- 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?
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?
- 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
Ansonsten wird immer geprüft:
Mit --fast wird der eigentliche Dateiinhalt nicht geprüft, ohne --fast wird der Hast nochmal vom aktuellen Dateiinhalt berechnet und verglichen.$ phlb verify --fast ~/PyHardLinkBackups/documents/2016-01-07-102310
Ansonsten wird immer geprüft:
- ist Datei überhaupt noch im Backup vorhanden
- Datei größe
- Hash in der Hash-Datei
- stat.st_mtime
- 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:
-> 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
Code: Alles auswählen
$ phlb add
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
- 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:
Gerade hab ich folgende Ausgaben mit chkdsk unter Windows:
Hm... Ob das mit den hardlinks zusammen hängt?!?...
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.
...
- jens
- Python-Forum Veteran
- Beiträge: 8502
- Registriert: Dienstag 10. August 2004, 09:40
- Wohnort: duisburg
- Kontaktdaten:
Das ist morgen und findet stattjens hat geschrieben:Geplant ist das selbe am 27.4. in Düsseldorf: http://www.pyddf.de/