Thema: Backup die zweite
https://checkmk.com/de/linux-wissen/loop-device-partitionieren
Eigentlich gehört das Thema ja eher zum Bereich AB4B, aber alles andere ist ja auch schon hier zusammen gefasst.
Und eigentlich wollte ich bei der DS ja ohne eigene Skripte auskommen - eigentlich.
Aber dann habe ich mir mal angesehen, was bei der Sicherung und Synchronisation mit AB4B so passiert.
Auf der DS wird für jede Sicherung ein eigenes Verzeichnis angelegt:
root@nas-ds224:~# ls -al /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/
total 0
drwxr-xr-x 1 ActiveBackup ActiveBackup 336 May 12 01:00 .
drwxr-xr-x 1 ActiveBackup ActiveBackup 232 May 12 01:00 ..
drwxr-xr-x 1 ActiveBackup ActiveBackup 80 May 2 19:40 ActiveBackup_2024-05-02_193917
drwxr-xr-x 1 ActiveBackup ActiveBackup 80 May 5 01:00 ActiveBackup_2024-05-05_010002
drwxr-xr-x 1 ActiveBackup ActiveBackup 80 May 12 01:00 ActiveBackup_2024-05-12_010001
Und in jedem Verzeichnis befinden sich die gleichen Dateien:
root@nas-ds224:~# ls -al /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-02_193917/
total 3374228
drwxr-xr-x 1 ActiveBackup ActiveBackup 80 May 2 19:40 .
drwxr-xr-x 1 ActiveBackup ActiveBackup 336 May 12 01:00 ..
-rw-r--r-- 1 ActiveBackup ActiveBackup 135168 May 2 19:40 backup_db.sqlite
-rw-r--r-- 1 ActiveBackup ActiveBackup 8904 May 2 19:39 device_spec
-rw-r--r-- 1 ActiveBackup ActiveBackup 10737418240 May 2 19:39 sda.img
In den beiden anderen Verzeichnissen sieht es ähnlich aus.
Hmm, bei total steht allerdings was von nur gut 3 Mio Blöcken (zu je 1 KB).
Also wird weniger Platz verbraucht als das ls suggeriert:
root@nas-ds224:~# du -hs /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/*
3.3G /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-02_193917
2.9G /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-05_010002
2.4G /volume1/ActiveBackupforBusiness/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-12_010001
Da scheint wohl eine Deduplikation am Werk zu sein und im Ergebnis sparsam mit dem Platz umzugehen - prima
Weniger prima sieht es auf dem Synchronisationsziel aus, hier unser Debian-VDR:
vdr-az:~# ls -al /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-02_193917/
total 10485916
drwxrwxr-x 2 rslsync rslsync 4096 13. Mai 15:59 .
drwxrwxr-x 5 rslsync rslsync 4096 13. Mai 15:17 ..
-rw-rw-r-- 1 rslsync rslsync 135168 2. Mai 19:40 backup_db.sqlite
-rw-rw-r-- 1 rslsync rslsync 8904 2. Mai 19:39 device_spec
-rw-rw-r-- 1 rslsync rslsync 10737418240 2. Mai 19:39 sda.img
vdr-az:~# du -hs /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/*
11G /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-02_193917
11G /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-05_010002
11G /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-12_010001
Das sieht dann doch eher so aus, als würden die Dateien dort mit ihrer nominalen Größe gespeichert werden.
Und das wiederum ist ziemlich böse, wenn die DS nicht die 1 beim 3-2-1 ist, sondern ihrerseits ihre Backups zu einer anderen 1 schaffen muss.
Dort wird dann nämlich ziemlich viel Platz für ziemlich wenig Daten verbraucht.
Deshalb habe ich mir als Nächstes mal so ein Image angesehen:
vdr-az:~# cd /mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-12_010001
vdr-az:/mnt/md5/sync/AB4B/ActiveBackupData/Server-vm-mail-Claus-Default/ActiveBackup_2024-05-12_010001# sfdisk -l sda.img
Disk sda.img: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8450ec9d
Device Boot Start End Sectors Size Id Type
sda.img1 * 2048 18970623 18968576 9G 83 Linux
sda.img2 18972670 20969471 1996802 975M 5 Extended
sda.img5 18972672 20969471 1996800 975M 82 Linux swap / Solaris
Das sieht doch verdächtig nach dem Dateisystem der VM aus.
Wenn man das dann nach der Beschreibung im Link ganz oben als Loop-Device mountet, stellt man fest, dass es tatsächlich das Dateisystem der VM ist.
Allerdings ohne die dort per mount eingebundenen Verzeichnisse.
Für die Mails in /home/vmail ist das gut, weil die ja sowieso direkt auf der DS liegen und gar nicht in das Backup sollen.
Für die nach tmpfs ausgelagerten Verzeichnisse unterhalb von /var ist das nicht so gut, weil die ja eigentlich dazu gehören.
Also muss so ein Pre-freeze-Skript her, das dafür sorgt, dass der Inhalt der tmpfs-Verzeichnisse gesichert wird:
Server-vm-mail-Pre-freeze.sh
Das besteht im Wesentlichen aus 2 Zeilen:
#!/bin/bash
/etc/init.d/var2tmpfs.sh save
Das geht in modern bestimmt auch mit sysctl - habe ich aber nicht ausprobiert.
Damit ist das Problem mit dem Speicherplatz aber noch nicht gelöst.
Also habe ich probehalber mal so ein Verzeichnis in ein tgz-Archiv gepackt und festgestellt, dass dadurch die 11 GB zu 670 MB schrumpfen.
Das ist doch schon deutlich angenehmer durch das Internetz zu verteilen.
Die nächsten Schritte waren dann:
Löschen des existierenden Sync und der auf den Zielsystemen damit angelegten Dateien
Ein neues Verzeichnis /volume1/ActiveBackupforBusiness/ActiveBackupData.sync anlegen und für den Sync vorbereiten
Das angehängte Skript entwickeln und so lange testen, bis es bei mir läuft
Das Skript in die Aufgabenplanung nach dem Backup aufnehmen und Resilio scharf schalten
BTW: Das Skript liegt bei mir in ActiveBackupData.sync und wird so gleich automatisch mit gesichert.
Und irgendwo in den KB von Synology steht, dass man bei Skripten absolute Pfadnamen verwenden soll, deshalb enthält es eine selbst für mich ordentliche Menge von runden und geschweiften Klammern.
Gruß
Claus
P.S.: sh-Dateien lassen sich hier nicht anhängen, deshalb die Umbenennung in txt