Business Datensicherungsaufgabe für benutzerdefiniertes Volume /dev/md1

[thc]

Hallo zusammen,

wir haben einen unter Debian 11 laufenden VDR (Video Disc Recorder), den ich mit AB4B sichern wollte.
Der hat mehrere RAID-1-Devices für boot, root, Daten und Backup
Das gesamte Gerät zu sichern macht wenig Sinn wegen der Menge an Aufnahmen im Daten-RAID.
Deshalb wollte ich ein Benutzerdefiniertes Volume auswählen, zuerst mal /dev/md1 mit /boot drin.
Da kommt dann aber leider nur ein "Das Gerät vdr-az ist offline" - obwohl es in der Übersicht einen grünen Punkt hat.
Wenn ich System-Volume auswähle, macht er das zwar ohne Murren.
Hinterher sind dann aber im Sicherungsverzeichnis md1.img (boot), md3.img (root) und sd[a-c].img (also die vollständigen Festplatten)

Frage deshalb: Wie bekomme ich nur /dev/md1 gesichert?

Gruß
Claus

 

[plang.pl]

Willst du das Volume an sich sichern oder reichen auch die Daten darauf? Wenn letzteres der Fall ist, reicht auch die AB4B Dateiserver-Sicherung.

 

[thc]

Schöner wäre eine md1.img als Ergebnis.
Aber wenn es auch anders geht - von mir aus.
Ich möchte nur nicht die 3 kompletten redundaten Platten als Image in der Sicherung haben.

Ansonsten bin ich zumindest einen Schritt weiter:
Nach Aushängen von /mnt/md2 (=/dev/md2) und /backup (=/mnt/md6) liess sich auch ein benutzerdefiniertes Volume auswählen.
Dann die Enttäuschung:
Im Angebot waren nur / und /mnt/md5, also die Mountpunkte für root und die ganzen Videos.
Ich habe dann / ausgewählt in der Hoffnung, nur das darunter liegende /dev/md3 als md3.img in der Sicherung wieder zu finden.
Aber nix - dasselbe Ergebnis wie bei der Auswahl von "System-Volume": md[13].img und sd[abc].img

Warum werden mir nur mounts angeboten und dann doch /dev gesichert - und dann auch noch ungefragt mehr?
So richtig schön wäre ja eine Liste zum Auswählen: alle /dev/sd* und alle /dev/md* und die dann als .img sichern - das wäre es.

Gruß
Claus

 

[thc]

Dateiserver-Sicherung ist wohl eher nicht drin.

Das Ziel ist ein Linux-Server, also rsync
Authentifizierung mit Passwort gibt es bei mir nicht, schon gar nicht für root von außen
Und ssh mit keyfile geht nur ohne Passphrase - gibt es bei mir auch nicht

Gruß
Claus

 

[maxblank]

Und wenn du den umgekehrten Backup-Weg nimmst?

https://kb.synology.com/de-de/DSM/tutorial/How_to_back_up_Linux_computer_to_Synology_NAS

 

[thc]

Das wird wohl funktionieren - schließlich basiert es auf rsync.
Damit geht aber der imho entscheidende Pluspunkt von ABfB verloren: das Image des dem Mountpoint zu Grunde liegenden Devices, basierend auf einem Snapshot.

Da bleibe ich besser bei der bisherigen Strategie:
Lokale Sicherung aller wichtigen Verzeichnisse mit rsync in eine gesonderte Partition und von da dann mit Resilio in die Welt, wann immer sich die Gelegenheit dazu bietet.

 

[thc]

Hat sich erledigt.

Ich habe ja in https://www.synology-forum.de/threads/mailserver-fuer-das-lan-in-einer-vm-auf-einer-ds.133338 dargestellt, wie ich das Backup des in einer VM laufenden Mailservers zu machen gedenke.
Warum nicht hier genauso - nur ein wenig angepasst?

Also zuerst mal nach dem tatsächlichen Platzbedarf geschaut:
root@nas-ds224:/volume1/ActiveBackupforBusiness.md/ActiveBackupData/Server-vdr-az-System-Volume# ll ActiveBackup_2024-05-18_175528/
total 9835928
drwxr-xr-x 1 ActiveBackup ActiveBackup 184 May 18 18:35 .
drwxr-xr-x 1 ActiveBackup ActiveBackup 216 May 18 18:35 ..
-rw-r--r-- 1 ActiveBackup ActiveBackup 352256 May 18 18:35 backup_db.sqlite
-rw-r--r-- 1 ActiveBackup ActiveBackup 49858 May 18 17:55 device_spec
-rw-r--r-- 1 ActiveBackup ActiveBackup 501612544 May 18 17:56 md1.img
-rw-r--r-- 1 ActiveBackup ActiveBackup 21474770944 May 18 18:35 md3.img
-rw-r--r-- 1 ActiveBackup ActiveBackup 2000398934016 May 18 17:55 sda.img
-rw-r--r-- 1 ActiveBackup ActiveBackup 2000398934016 May 18 17:55 sdb.img
-rw-r--r-- 1 ActiveBackup ActiveBackup 2000398934016 May 18 17:55 sdc.img
Auffällig ist wieder die Angabe bei total, die auf knapp 10 GB hinweist - sonst wäre es auch heftig viel für die DS.

Der tatsächliche Verbrauch an Plattenplatz ist:
root@nas-ds224:/volume1/ActiveBackupforBusiness.md/ActiveBackupData/Server-vdr-az-System-Volume# du -hs ActiveBackup_2024-05-18_175528/*
344K ActiveBackup_2024-05-18_175528/backup_db.sqlite
52K ActiveBackup_2024-05-18_175528/device_spec
269M ActiveBackup_2024-05-18_175528/md1.img
9.2G ActiveBackup_2024-05-18_175528/md3.img
4.1M ActiveBackup_2024-05-18_175528/sda.img
4.1M ActiveBackup_2024-05-18_175528/sdb.img
4.1M ActiveBackup_2024-05-18_175528/sdc.img
Damit lässt sich leben, solange man nicht versucht, sd*.img woanders hin zu verfrachten.
Es sei denn natürlich, man hat dort reichlich Platz zur Verfügung.
Ich vermute auf Grund meiner bisherigen Tests nämlich, dass dann die Images auf die vollen 2 TB aufgeblasen werden.

Wirklich Interesse habe ich aber nur an md1.img und md3.img.
Dafür habe ich mein Skript etwas erweitert, um nur diese beiden Dateien weg zu sichern.
Das Ergebnis:
root@nas-ds224:/volume1/ActiveBackupforBusiness.sync/ActiveBackupData# ll Server-vdr-az-System-Volume/ActiveBackup_2024-05-18_175528/
total 2861552
d---------+ 1 root root 28 May 18 20:51 .
d---------+ 1 root root 60 May 18 20:51 ..
----------+ 1 root root 2930225504 May 18 20:59 2024-05-18.tgz
Also knapp 3 GB - für einen ausgewachsenen Linux-Server angemessen.
Das wird jetzt zusammen mit den anderen ABfB-Sicherungen mit Resilio weg synchronisiert und gut ist.
Das erweiterte Skript habe ich wieder als txt angehangen.

Ich werde für mich auch mal ausprobieren, wie viel Platz es braucht, wenn ich das ganze Verzeichnis in ein tgz packe.
These: Nicht wirklich mehr - man darf dann nur nicht versuchen, das komplett wieder auszupacken.
Wobei: Auf einem System mit Dateideduplikation sollte das sogar funktionieren.

Gruß
Claus