Der Treff ist zur üblichen Zeit am üblichen Ort
Inhaltsverzeichnis
1. Zusammenfassung des Treffs
(aus den E-Mails unserer Mailling-Liste erstellt, Werner)
Hallo,
es waren wieder rege Diskussionen. Insbesondere um UEFI/Secure Boot.
Andere Themen waren:
1.1. krename
kann viele Dateien auf einen Rutsch umbenennen.
Nach dem Start gibt es 4 Reiter.
- Links (1) der zum Hinzufügen der zu bearbeitenden Dateien.
- Dann kommt (2) das Ziel: umbenennen.
- (3) Plugins: Hier zum Beispiel die Datums und System-Funktionen: Man sieht z.B. [filesize]
- Unter (4) Dateiname sieht man dann die Gegenüberstellung von altem und neuem Dateinamen. Beispielsweise wählt man den Reiter "Einfacher Dateiname" und trägt im Feld Suffix "_[filesize]" (ohne Anführungsstreiche) ein und sieht untendrunter das zu erwartende Ergebniss.
Einfaches Ersetzen geht so: Im Reiter "Fortgeschrittenen-Modus" "Suchen und Ersetzen" wählen. "Hinzufügen" wählen und die Zeichenketten eingeben. In der Vorschau sieht man wiederum das zu erwartende Ergebniss.
1.2. Wie finde ich Duplikate
Hier ist "Link to dir" erwähnt worden.
Andere:
http://www.pixelbeat.org/fslint/ (erkennt auch ungültige Namen)
http://www.ghacks.net/2010/03/22/duplicate-file-finder-duper/
und für die schon abgehärteten:
http://www.gentoofreunde.org/node/537
http://www.unixboard.de/vb3/showthread.php?36365-Doppelte-Dateien-finden-und-l%F6schen
http://wiki.debianforum.de/Doppelte_Dateien_löschen
http://deritwahnsinn.blogspot.de/2010/02/doppelte-dateien-finden.html
und hier für die ganz abgehärteten:
1.3. storebackup
Da hatte ich auch eine Frage nach der Verfallzeit. Bei der Diskussion kamen kulturelle Unterschiede zutage, wie man mit eigenen Dateien umgeht. Ich habe aus alten VMS-Tagen die Sitte beibehalten, Dateien nicht zu überschreiben, sondern an den Dateinamen eine Versionszahl hinzuzufügen. Das Filesystem von VMS hatte das automatisch gemacht. Zurück zu storebackup: wie konfiguriere ich das, damit in der Sicherung eine Geschichte der Quelle entsteht? Beispiel: Vor einer Woche habe ich die Datei test.txt in der Quelle erstellt. Jeden Tag wird ein Sicherungslauf gemacht. Heute lösche ich die Datei in der Quelle. Und ich möchte, dass in der Zukunft diese Datei in der Sicherung nie gelöscht wird. Ist das gleichbedeutend mit: minimale Anzahl der Hardlinks=1? Ist es sinnvoll 2 Hardlinks zu haben: aus dem ersten und letzten Sicherungslauf, wo die Datei (unverändert) existiert hat?
Datenintegrität (sind meine Daten in der Quelle noch in Ordnung) Hatten wir beim vorletzten Treffen kurz diskuttiert.
Einig war man sich auch in der Feststellung, dass (mindestens) eine Sicherung nicht am Ort der Quelle gelagert werden sollte. Grund: Flugzeugabstürze, Brand
Ich kann einfach eine Festplatte einem Bekannten zur Aufbewahrung übergeben. Geht das auch etwas bequemer?
Hallo Joachim,
zu den storeBackup-Fragen:
Es wird immer der gesamte Quellpfad gesichert (also das, was Du in der Konfigurationsdatei als "sourceDir" definierst). Damit Deine täglichen Backups nicht gelöscht werden, setzt Du ungefähr in Zeile 390
doNotDelete=yes
Da Du alle Backups behalten willst, brauchst Du eigentlich keine keep-Regeln zu definieren (wie z.B. keepFirstOfYear usw.).
Möglicherweise ist aber für die Versionierung einer Datei eine Versionsverwaltung besser geeignet.
Mit platzsparenden mehrfachen Hardlinks auf denselben Inode hat dieses Szenario übrigens nicht sehr viel zu tun: Ein Hardlink zeigt direkt auf einen Inode (also auf den Bereich der Festplatte, auf dem eine Datei abgelegt ist). Man kann mehrere Hardlinks zu diesem Plattenplatz anlegen, die auch unterschiedliche Namen tragen können, aber dennoch immer dieselben Daten (also denselben Inode) aufrufen. Symbolische Links dagegen verknüpfen auf einen Hardlink oder einen anderen symbolischen Link, sie rufen die Datei also nur mittelbar - letztendlich über den Hardlink - auf.
Die bewusste Datei wird aber (fast) täglich geändert; damit ist auch jedes Mal ein neuer Inode notwendig - also wird auch jedes Mal ein neuer Hardlink auf den neuen Inode angelegt. Nur bei unveränderten Dateien sparst Du also Platz, weil der bereits vorhandene Inode dann per zusätzlichem Hardlink gesichert wird.
Bei größeren Dateien wäre vielleicht die Option "blocked files" interessant; hier wird die Datei in einzelne Häppchen aufgeteilt, die dann (ggf. komprimiert) gespeichert werden können; beim Backup werden dann nur die veränderten Dateiblöcke gespeichert, der Rest wird verhardlinkt.
Gruß
Frank
Hallo und Lieber Frank,
herzlichen Dank für deine Antwort. Hier eine Messung des Platzverbrauches. Methode: zwei mal storebackup laufen lassen, dazwischen sind keine Änderungen in den zu sichernden Dateien.
du -sh -B K 275564392K storeBackup --sourceDir /.../Dokumentendigitalisierung/ --backupDir /.../storebackup/test1/ --doNotDelete VERSION 2012.09.28 09:01:37 22992 storeBackup.pl, 3.2, build 361 INFO 2012.09.28 09:01:37 22992 setting ARG_MAX to 63488 (Linux) INFO 2012.09.28 09:01:37 22992 comprRule = $size > 1024 and not $file =~ /\.zip\Z|\.bz2\Z|\.gz\Z|\.tgz\Z|\.jpg\Z|\.gif\Z|\.tiff\Z|\.tif\Z|\.mpeg\Z|\.mpg\Z|\.mp3\Z|\.ogg\Z|\.gpg\Z|\.png\Z/i WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.08.27_09.35.02> not finished WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.09.28_08.56.14> not finished WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.09.28_08.59.24> not finished WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.08.27_09.35.02> not finished WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.09.28_08.56.14> not finished WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.09.28_08.59.24> not finished INFO 2012.09.28 09:01:37 22992 scanning directory </.../storebackup/test1> for existing backups INFO 2012.09.28 09:01:37 22992 scanning directory </.../storebackup/test1/default> for existing backups STATISTIC 2012.09.28 09:01:37 22992 found 2 backup series, 12 backups, 0 renamed backups INFO 2012.09.28 09:01:37 22992 consistency check finished successfully INFO 2012.09.28 09:01:37 22992 found no references to other backups INFO 2012.09.28 09:01:37 22992 removing old lock file of process <22974> INFO 2012.09.28 09:01:37 22992 creating lock file </tmp/storeBackup.lock> WARNING 2012.09.28 09:01:37 22992 /.../storebackup/test1/default/2012.09.28_08.59.24 not finished, skipping WARNING 2012.09.28 09:01:37 22992 /.../storebackup/test1/default/2012.09.28_08.56.14 not finished, skipping WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.08.27_09.35.02> not finished WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.09.28_08.56.14> not finished WARNING 2012.09.28 09:01:37 22992 backup </.../storebackup/test1/default/2012.09.28_08.59.24> not finished INFO 2012.09.28 09:01:37 22992 analysis of old Backups in </.../storebackup/test1/default>: INFO 2012.09.28 09:01:37 22992 Sat 2012.08.25_11.04.05 (33d21h): keepMinNumber9 INFO 2012.09.28 09:01:37 22992 Sat 2012.08.25_11.20.45 (33d21h): keepMinNumber8 INFO 2012.09.28 09:01:37 22992 Mon 2012.08.27_11.11.15 (31d21h): keepMinNumber7 INFO 2012.09.28 09:01:37 22992 Wed 2012.08.29_19.37.08 (29d13h): keepMinNumber6, keepWeekDays(30d) INFO 2012.09.28 09:01:37 22992 Sat 2012.09.01_12.43.27 (26d20h): keepMinNumber5, keepWeekDays(30d) INFO 2012.09.28 09:01:37 22992 Mon 2012.09.10_09.58.08 (17d23h): keepMinNumber4 INFO 2012.09.28 09:01:37 22992 Mon 2012.09.10_10.02.09 (17d22h): keepMinNumber3, keepWeekDays(30d) INFO 2012.09.28 09:01:37 22992 Sun 2012.09.16_08.58.18 (12d0h): keepMinNumber2, keepWeekDays(30d) INFO 2012.09.28 09:01:37 22992 Fri 2012.09.28_07.36.31 (0d1h): keepDuplicate(7d) INFO 2012.09.28 09:01:37 22992 Fri 2012.09.28_09.01.37 (0d0h): keepMinNumber1, keepWeekDays(30d) INFO 2012.09.28 09:01:37 22992 start reading /.../storebackup/test1/default/2012.09.28_07.36.31/.md5CheckSums.bz2 INFO 2012.09.28 09:01:47 22992 finished reading /.../storebackup/test1/default/2012.09.28_07.36.31/.md5CheckSums.bz2 (310688 entries) INFO 2012.09.28 09:01:47 22992 297657 entries in dbm files INFO 2012.09.28 09:01:47 22992 0 entries in dbm block files INFO 2012.09.28 09:05:42 22992 setting atime, mtime of directories ... STATISTIC 2012.09.28 09:05:42 22992 [sec] | user| system STATISTIC 2012.09.28 09:05:42 22992 -------+----------+---------- STATISTIC 2012.09.28 09:05:42 22992 process| 96.61| 37.80 STATISTIC 2012.09.28 09:05:42 22992 childs | 9.88| 1.79 STATISTIC 2012.09.28 09:05:42 22992 -------+----------+---------- STATISTIC 2012.09.28 09:05:42 22992 sum | 106.49| 39.59 => 146.08 (2m26s) STATISTIC 2012.09.28 09:05:42 22992 directories = 13031 STATISTIC 2012.09.28 09:05:42 22992 files = 297657 STATISTIC 2012.09.28 09:05:42 22992 symbolic links = 0 STATISTIC 2012.09.28 09:05:42 22992 late links = 0 STATISTIC 2012.09.28 09:05:42 22992 named pipes = 0 STATISTIC 2012.09.28 09:05:42 22992 sockets = 0 STATISTIC 2012.09.28 09:05:42 22992 block devices = 0 STATISTIC 2012.09.28 09:05:42 22992 character devices = 0 STATISTIC 2012.09.28 09:05:42 22992 new internal linked files = 0 STATISTIC 2012.09.28 09:05:42 22992 old linked files = 297657 STATISTIC 2012.09.28 09:05:42 22992 unchanged files = 297657 STATISTIC 2012.09.28 09:05:42 22992 copied files = 0 STATISTIC 2012.09.28 09:05:42 22992 compressed files = 0 STATISTIC 2012.09.28 09:05:42 22992 blocked files = 0 STATISTIC 2012.09.28 09:05:42 22992 excluded files because rule = 0 STATISTIC 2012.09.28 09:05:42 22992 included files because rule = 0 STATISTIC 2012.09.28 09:05:42 22992 max size of copy queue = 0 STATISTIC 2012.09.28 09:05:42 22992 max size of compression queue = 0 STATISTIC 2012.09.28 09:05:42 22992 calculated md5 sums = 0 STATISTIC 2012.09.28 09:05:42 22992 forks total = 0 STATISTIC 2012.09.28 09:05:42 22992 forks md5 = 0 STATISTIC 2012.09.28 09:05:42 22992 forks copy = 0 STATISTIC 2012.09.28 09:05:42 22992 forks bzip2 = 0 STATISTIC 2012.09.28 09:05:42 22992 sum of source = 112G (120138967329) STATISTIC 2012.09.28 09:05:42 22992 sum of target all = 224G (240277934658) STATISTIC 2012.09.28 09:05:42 22992 sum of target all = 200.00% STATISTIC 2012.09.28 09:05:42 22992 sum of target new = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 sum of target new = 0.00% STATISTIC 2012.09.28 09:05:42 22992 sum of md5ed files = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 sum of md5ed files = 0.00% STATISTIC 2012.09.28 09:05:42 22992 sum internal linked (copy) = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 sum internal linked (compr) = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 sum old linked (copy) = 109G (116571175956) STATISTIC 2012.09.28 09:05:42 22992 sum old linked (compr) = 3.3G (3567791373) STATISTIC 2012.09.28 09:05:42 22992 sum unchanged (copy) = 109G (116571175956) STATISTIC 2012.09.28 09:05:42 22992 sum unchanged (compr) = 3.3G (3567791373) STATISTIC 2012.09.28 09:05:42 22992 sum new (copy) = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 sum new (compr) = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 sum new (compr), orig size = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 sum new / orig = 0.00% STATISTIC 2012.09.28 09:05:42 22992 size of md5CheckSum file = 9.9M (10350083) STATISTIC 2012.09.28 09:05:42 22992 size of temporary db files = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 deleted old backups = 0 STATISTIC 2012.09.28 09:05:42 22992 deleted directories = 0 STATISTIC 2012.09.28 09:05:42 22992 deleted files = 0 STATISTIC 2012.09.28 09:05:42 22992 (only) removed links = 0 STATISTIC 2012.09.28 09:05:42 22992 freed space in old directories = 0.0 (0) STATISTIC 2012.09.28 09:05:42 22992 add. used space in files = 9.9M (10350083) STATISTIC 2012.09.28 09:05:42 22992 backup duration = 4m5s STATISTIC 2012.09.28 09:05:42 22992 over all files/sec (real time) = 1214.93 STATISTIC 2012.09.28 09:05:42 22992 over all files/sec (CPU time) = 2037.63 STATISTIC 2012.09.28 09:05:42 22992 CPU usage = 59.62% INFO 2012.09.28 09:05:42 22992 removing lock file </tmp/storeBackup.lock> WARNING 2012.09.28 09:05:42 22992 -- 11 WARNINGS OCCURED DURING THE BACKUP! -- INFO 2012.09.28 09:05:42 22992 syncing ... du -sh -B K 275631412K Ergebniss: diff 67020K = 65,45MByte Pro File: 230,5 Byte.
Frage1: ist die Messmethode mit du richtig?
Warum nicht?
Du legst hard links und Directories an. Bei einem hard link benötigst Du den Platz für den hard link, beim Directory mindestens den Platz für den Inode sowie 2 x hard links.(also den Namen und "." sowie ein weiterer hard link für jedes Unterverzeichnis, also ".."). Je nach Filesystem wird der Platz für den Inode schon beim Anlegen des Filesystem reserviert (ext) oder auch nicht (reiserfs, btrfs).
Der Bedarf pro Datei dürfte also etwas niedriger sein (wg. zus. Directorie- Einträge) - wenn man's genau nimmt. Der Wert ist natürlich auch vom verwendeten Dateisystem abhängig.
Nur so: hard links auf Directory Inodes werden vom Filesystem automatisch verwaltet, als gewöhnlicher Sterblicher kommt man da nicht ran.
Sonstige Bemerkungen?
Frage2: Ist es von Bedeutung, wenn man storebackup von der Kommandozeile (wie oben) von unterschiedlichen Rechnern ausführt? Dabei sind die Pfade identisch (nfs mounts).
Wenn die Pfade identisch sind, werden die md5 Summen für unveränderte Dateien nicht neu berechnet. Wenn die Pfade unterschiedlich wären, dann schon. Doppelte Dateien werden so oder so erkannt.
Ich verstehe allerdings nicht so ganz, wozu Du das machen willst. Wenn Du zwei unterschiedliche Rechner sichern willst, ist es idR. sinnvoller, zwei "backup series" zu verwenden.
Falls Du allerdings eine externe USB Platte mal von Rechner A und mal von Rechner B sichern willst, macht es natürlich sehr viel Sinn.
Grüße, Heinz-Josef
1.4. recoll
mein Scanner ist ein Fujitsu S1500.
Mehr zu "Suchen und Finden" unter Allerlei HowTo's
Ich bin beim nächsten Treffen im Urlaub.
Gruss, Joachim