staging.inyokaproject.org

Hallo,

ich möchte eine Sicherungskopie meines statischen Datenverzeichnisses auf in ein anderes Verzeichnis auf einem anderen Datenträger erstellen. Beide Orte haben, soweit ich das beurteilen kann, die gleichen Berechtigungen und das gleiche Dateisystem. Am Ende des Kopiervorgangs sollten also die Summen der Dateien/Dateigrößen exakt gleich sein. Ich habe den Kopiervorgang erst mit Doplhin und dann mit Midknight Commander probiert. In beiden Fällen ging es nicht ohne Fehlermeldung ab. Schließlich verwendete ich cp. Das lief klaglos. Dann wollte ich prüfen, ob der Kopiervorgang vollständig war und verglich zunächst mal nur die Summen. Sie weichen immer wieder ab:

1
2
3

$ cp -ruv /mnt/kry/ich /mnt/bck24/daten ;  du -s /mnt/kry/ich ; du -s /mnt/bck24/daten/ich
5304496212      /mnt/kry/ich
5304501044      /mnt/bck24/daten/ich

cp macht trotz -v keine Ausgabe, was ich als "vollständig" interpretiere.

Die Abweichung ist aber in der Summe der Dateigrößen vorhanden, wie man an den beiden du-Befehlen sieht.

Auf die Quelle greifen theoretisch Thunderbird und Owncloud zu. Beides hatte ich aber für den Vergleich beendet. Es handelt sich um lokale Datenträger ohne Netzfreigaben.

$ mount | grep -i "mapper"
/dev/mapper/kry on /mnt/kry type ext4 (rw,relatime)
/dev/mapper/luks-8a3d6f60-285b-4f74-9021-e9d8b898e122 on /mnt/bck24 type ext4 (rw,relatime)

Offene Dateien oder Zeiger:

lsof | grep -i "kry"
mc        33226                                   p  cwd       DIR              252,0        4096  100335617 /mnt/kry/ich
bash      33228                                   p  cwd       DIR              252,0        4096  100335617 /mnt/kry/ich

Ich glaube nicht, dass mc oder bash eine Datei in der Quelle aufhaben. Im Ziel ist die Ausgabe von lsof leer.

Wie vergleichen? Ich habe es mit diff versucht:

$ diff -r /mnt/kry/ich /mnt/bck24/daten/ich
Nur in /mnt/bck24/daten/ich/owncloud: .sync_journal.db-shm.
Nur in /mnt/bck24/daten/ich/owncloud: .sync_journal.db-wal.
        diff: /mnt/kry/ich/privat/[...]/.mozilla/firefox/2axidacr.uk/lock: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/privat/[...]/.mozilla/firefox/2axidacr.uk/lock: Datei oder Verzeichnis nicht gefunden
        diff: /mnt/kry/ich/privat/[...]/.mozilla/firefox/mwad0hks.default/lock: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/privat/[...]/.mozilla/firefox/mwad0hks.default/lock: Datei oder Verzeichnis nicht gefunden
        diff: /mnt/kry/ich/privat/[...]/.thunderbird/mwrrhtkq.default/lock: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/privat/[...]/.thunderbird/mwrrhtkq.default/lock: Datei oder Verzeichnis nicht gefunden
        diff: /mnt/kry/ich/tbmail/lock: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/tbmail/lock: Datei oder Verzeichnis nicht gefunden
        diff: /mnt/kry/ich/unsortiertes/2022/2022-transfer/p/.config/menus/mate-applications-merged: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/unsortiertes/2022/2022-transfer/p/.config/menus/mate-applications-merged: Datei oder Verzeichnis nicht gefunden
        diff: /mnt/kry/ich/unsortiertes/2022/2022-transfer/p/.mozilla/firefox/m2yi5z7l.default-release/lock: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/unsortiertes/2022/2022-transfer/p/.mozilla/firefox/m2yi5z7l.default-release/lock: Datei oder Verzeichnis nicht gefunden
Nur in /mnt/bck24/daten/ich/wolke: .sync_journal.db-shm.
Nur in /mnt/bck24/daten/ich/wolke: .sync_journal.db-wal.
        diff: /mnt/kry/ich/z_Sicher/[...]/.pulse/8375a466d2b147593271228800000008-runtime: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/z_Sicher/[...]/.pulse/8375a466d2b147593271228800000008-runtime: Datei oder Verzeichnis nicht gefunden
        diff: /mnt/kry/ich/z_Sicher/[...]/Ubuntu One/Shared With Me: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/z_Sicher/[...]/Ubuntu One/Shared With Me: Datei oder Verzeichnis nicht gefunden
        diff: /mnt/kry/ich/z_Sicher/tbmail-2023-11-12-1841-mit-[...]/lock: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/z_Sicher/tbmail-2023-11-12-1841-mit-[...]/lock: Datei oder Verzeichnis nicht gefunden
        diff: /mnt/kry/ich/z_Sicher/z_Privat-Backup/tb-backup/tbmail-bck-2023-05-06-1446/lock: Datei oder Verzeichnis nicht gefunden
diff: /mnt/bck24/daten/ich/z_Sicher/z_Privat-Backup/tb-backup/tbmail-bck-2023-05-06-1446/lock: Datei oder Verzeichnis nicht gefunden

Die Stellen mit [...] sind Kürzungen von mir. Es handelt sich nur um Verzeichnisnamen ohne Umlaute/Sonderzeichen.

Die gefundenen Abweichungen sind Lock-Dateien von Programmen, die nicht aktiv waren, zum Teil seit Jahren nicht mehr.

Es sind aber bis auf die Funde bei owncloud und wolke alles nur Paare. Das heißt, cp hat diese Dateien kopiert, und diff kann mit ihnen nicht umgehen, liefert eine unsinnige Auskunft.

Um das Problem mit owncloud und wolke zu beseitigen, ohne erneut alles löschen um den cp-Befehl erneut laufen lassen zu müssen, habe ich rsync zur Synchronisation genommen. Zunächst mit den Parametern -av --delete, dann so:

$ rsync -avc --progress --delete /mnt/kry/ich /mnt/bck24/daten ; du -sbl /mnt/kry/ich ; du -sbl /mnt/bck24/daten/ich

Die Ausgabe ist:

p@geist:~$ rsync -av --size-only --stats --progress --delete /mnt/kry/ich /mnt/bck24/daten ; du -sbl /mnt/kry/ich ; du -sbl /mnt/bck24/daten/ich
sending incremental file list

Number of files: 1.074.372 (reg: 1.012.219, dir: 61.311, link: 842)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 0
Total file size: 5.429.467.415.101 bytes
Total transferred file size: 0 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 9.369.812
File list generation time: 0,001 seconds
File list transfer time: 0,000 seconds
Total bytes sent: 33.372.286
Total bytes received: 66.390

sent 33.372.286 bytes  received 66.390 bytes  1.486.163,38 bytes/sec
total size is 5.429.467.415.101  speedup is 162.370,88
5304586944      /mnt/kry/ich
5304591188      /mnt/bck24/daten/ich

Jetzt kann ich mir aussuchen, wie groß die Summe der Dateigrößen ist:

5.429.467.415.101 Bytes laut rsync 
5.429.753.340.477   auf /mnt/kry/ich laut du
5.429.751.214.653   auf /mnt/bck24/daten/ich laut du

Vielleicht rührt der Unterschied zwischen du und rsync daher, dass das eine Programm Hardlinks und/oder Verzeichnisse mitzählt und das andere nicht. Aber die beiden du-ausgaben sollten doch bei gleichen Parametern bitte gleich sein. Die rsync-Ausgabe ist jetzt immer gleich, was bedeutet, dass sich in Quelle und Ziel wirkliche nichts mehr geändert hat (durch ownclou, wolke oder sonstwas).

Letztlich will ich, dass auf dem Ziel exakt das ist, was es in der Quelle gibt. Sonst ist es kein vollständiges Backup.

Wie erreiche ich das bitte?

Danke & Gruß

Delcour

Hallo delcour,

wie heißt es so schön: "Wer viel misst, misst Mist". Aber so kann man halt feststellen, dass beim Vergleich von Äpfeln mit Birnen tatsächlich Unterschiede zu finden sind.

Ich habe mal das Verzeichnis "~/.config" per "cp -ruv" nach "~/x/" kopiert und natürlich die von dir auch festgestellten Unterschied ausgemacht. Ein Beispiel:

$ du -s .config/
249908	.config/
$ du -s x/.config/
249172	x/.config/
$ stat .config/calibre/fonts/scanner_cache.json
  Datei: .config/calibre/fonts/scanner_cache.json
 Größe: 958263    	Blöcke: 1880       EA Block: 4096   Normale Datei
Gerät: 805h/2053d	Inode: 3818156     Verknüpfungen: 1
Zugriff: (0664/-rw-rw-r--)  Uid: ( 1000/ shiro)   Gid: ( 1000/ shiro)
Zugriff: 2024-03-02 18:07:58.474157136 +0100
Modifiziert: 2024-02-15 22:37:23.780368757 +0100
Geändert: 2024-02-15 22:37:23.788368192 +0100
Geburt: 2024-02-15 22:37:23.780368757 +0100
$ stat x/.config/calibre/fonts/scanner_cache.json
  Datei: x/.config/calibre/fonts/scanner_cache.json
 Größe: 958263    	Blöcke: 1872       EA Block: 4096   Normale Datei
Gerät: 805h/2053d	Inode: 397954      Verknüpfungen: 1
Zugriff: (0664/-rw-rw-r--)  Uid: ( 1000/ shiro)   Gid: ( 1000/ shiro)
Zugriff: 2024-03-02 18:07:58.474157136 +0100
Modifiziert: 2024-03-02 18:07:58.478157174 +0100
Geändert: 2024-03-02 18:07:58.478157174 +0100
Geburt: 2024-03-02 18:07:58.474157136 +0100
$ 

An obigem Beispiel siehst du, dass die Bytes bei "Größe:" gleich sind, bei "Blöcke:" sich aber unterscheiden. Der "du" Befehl betrachtet Blöcke und rechnet diese in Bytes um (z.B. *512). Aber auch wenn du einen

$ find .config -type f -printf "%s %p\n"

machst, wirst du Unterschiede feststellen. Meist sind Unterschiede bei Verzeichnissen zu finden. Ein weiterer Grund ist, dass Dateien durchaus nach dem Kopieren vom System verändert werden.

In anderen Worten: Du interpretierst mehr in die "du" Aussage herein als sie dir anzeigt. Für eine "Datensicherung" ist "cp" sicher nicht ganz so gut geeignet, wie eine "Snapshot"-Sicherung, wie sie z.B. "Drive SnapShot" bietet, die aber bei Linux nicht so üblich ist.

Mit cp oder mit einem Dateimanager macht man keine Datensicherung!

Das Mittel der Wahl ist rsync. Hier im Wiki gibt es eine hervorragende Beschreibung und Skripte: https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC/. Auf diese Weise mache ich seit Jahren meine Datensicherung. Die Hauptvorteile sind für mich: 1. es werden keine Tools benötigt, um die Sicherungen zu überprüfen oder gesicherte Dateien anzusehen oder zurückzukopieren. Der vorhandene Dateimanager reicht dafür vollkommen. 2. Die Sicherung kann man so oft wiederholen wie gewünscht; eine aus welchem Grund auch immer abgebrochene Sicherung kann wiederholt werden. 3. Die Sicherung ist Platz sparend dank Hard Links. 4. Einzelne Sicherungs-Ordner dürfen sogar problemlos und ohne Nachteile gelöscht werden. 5. Es gibt hier keine "Master"-Sicherung, auf die alle nachfolgenden Sicherungen aufbauen müssen.

Ein Nachteil könnte sein, dass übergrosse Dateien, z. B. Images von virtuellen Maschinen, immer in Gänze kopiert werden.

Mein zu sichernder Datenbestand sind ca. 700 Gigabytes. Die allererste Sicherung ist natürlich eine Komplettkopie und nimmt genau so viel Platz ein, aber die nachfolgenden täglichen Sicherungen (ohne solche Images) benötigen pro Sicherung so wenig Platz, dass ich auf meinem 2 TB-Sicherungslaufwerk nach über 300 Tagessicherungen immer noch 350 GB frei habe.

Übrigens funktioniert auch Time Machine von Apple genau so, nämlich mit rsync. Sie haben halt nur ein bisschen optisches Apple-Blingbling und einen stündlich laufenden Automatismus hinzugefügt.

du ist hier nicht so ein taugliches Mittel, weil es den Platz auf dem Datenträger mísst, der selbst bei identischem Inhalt verschieden sein kann. Besser nimmt man die Dateilänge und lässt die Verzeichnisse außen vor:

1

find -type f -printf '%s\n' | awk '{s+=$1} END {print s}'

Eine andere, langsamere Variante ist md5sum zu nutzen. Damit kann man dann auch den Inhalt überprüfen.

1
2
3
4
5
6
7
8

t(){
  ( cd "$1" && find -type f -print0 | sort -z | xargs -r0 md5sum )
}

t quelle >/tmp/d1
t ziel >/tmp/d2

diff -U3 /tmp/d1 /tmp/d2

Vielen Dank! Das war sehr hilfreich von Euch.

Dauerhaft werde ich das Backup wieder mit rsync machen, eine Quelle, zwei prinzipiell gleiche Ziele, aber mit sich abwechselnden Zieldatenträgern.

Momentan bereite ich vor, den aktuellen "Produktiv"-Datenträger (8 TB) durch einen neuen (12 TB) zu ersetzen. Nur deswegen setzte ich cp ein, weil ich auf eine leere Platte schrieb. Bei der Kontrolle, ob alles im Ziel angekommen ist, stieß ich auf die erwähnten Probleme.

Die Funktion t() von rklm ist gerade am arbeiten. Zuvor musste ich freilich den rsync-Befehl wiederholen, der effektiv 2 Tage bis zur Fertigstellung gebraucht hat. "Effektiv" meint hier, dass ich bedingt durch Nachtschlaf und Berufstätigkeit und Kinder meist erst am späten Abend nachsehen und weitermachen kann.

Das finale Ergebnis der Prüfung habe ich darum noch nicht, aber ich bin zuversichtlich, dass es gut werden wird.

Bei meinem Einsatz des diff-Befehls waren die so entstandenen Textdateien wegen unterschiedlicher Sortierung für einen Zeilenvergleich unbrauchbar. Aber der "sort"-Einsatz in rklms t()-Funktion berücksichtigt auch das Problem, über welches ich hier gar nicht geschrieben hatte.

Das ist nur eine Zwischenmeldung. Wenn es fertig ist, werde ich berichten und voraussichtlich den Thread als gelöst schließen.

Nach 12 Stunden hat t() ein paar Dutzend Dateien ausgegeben, die ich teilweise gelöscht und den Rest umbenannt habe, indem ich einfach einen Unterstrich anfügte, was offenbar versteckte Zeichencodes entfernte.

Danach liefert die Prüfung keine Unterschiede zwischen Quelle und Ziel mehr.

Danke nochmals!