Business Linux: ABB Backup von luks Partition

[migieger]

Das ging in 2022 lt. https://www.synology-forum.de/threads/linux-backup-von-luks-partition.122737/ nicht.
Geht das evtl. heute?

Bzw. hat jemand eine verschlüsselte (System)Partition erfolgreich von ABB backup'en lassen? Wenn ja, wie?

Hintergrund: ich habe eine unverschlüsselte Linux-Systempartition problemlos mit ABB backup'en lassen.
Nachdem ich das System in eine unverschlüsselte /boot-Partition und eine / (root)-LUKS verschlüsselte Partition überführt hatte, konnte ABB nur noch die unverschlüsselten /boot (und /boot/efi) backup'en. In den logs finde ich sinngemäß "nvmex wird nicht gebackup't (nicht unterstütztes Filesystem)". Und das obwohl die betreffende Partition via /dev/mapper/nvme_crypt entschlüsselt und gemounted ist...

Eigentlich wollte ich ja mit dem Supportende von Windows 10 im Okt. auf Linux wechseln. Aber ein Laptop mit verschlüsselter SSD, der nicht gebackup't werden kann?
Dann wahrsch. doch eher Windows 11?

 

[Adama]

Siehe hier:
https://www.synology.com/de-de/dsm/...mponent__admin_console__physical_server_linux

 

[migieger]

Ja, bekannt. Ebenso wie https://www.synology.com/de-de/dsm/7.2/software_spec/abb
In beiden ist /dev/mapper nicht aufgeführt :-(

Dann bleibt wohl die Frage:
Bzw. hat jemand eine verschlüsselte (System)Partition erfolgreich von ABB backup'en lassen? Wenn ja, wie?

 

[Adama]

Ich stell grad fest, das ich auf meinem checkmk-Testrechner tatsächlich /dev/mapper sichere. Das ist mir bisher gar nicht bewusst gewesen. Letztlich ist /dev/mapper/etc auf / gemountet.

Das Filesystem im LVM ist allerdings "nur" ext4 und nicht verschlüsselt.

Ich kann auch auf die Sicherungen zugreifen und sehe den Inhalt im Portal. Also grundsätzlich scheint es doch kein Problem zu sein, ein LVM zu sichern, wenn das darin liegende Volume ein unterstütztes Dateisystem beinhaltet.

Ich frag mich grade, ob das nicht eigentlich wie bei Windows sein müsste: Ein Bitlocker-verschlüsseltes Volume lässt sich ja im Betrieb sichern, da dann das Volume ja entschlüsselt ist und nichts anderes als ein NTFS-Filesytem enthält.

Sieht das bei LUKS ähnlich aus? Also wenn das Volume entschlüsselt ist, sieht man nicht anderes, als z.B: ein ext4?

Mount auf Kommandozeile zeigt u.a. dies:

/dev/mapper/GalacticaCheckMK--vg-root on / type ext4 (rw,relatime,errors=remount-ro)

Das sehe ich im ABfB-Portal:

 

[migieger]

Interessant! Danke.

So schaut"s hier aus:

root@P3U:~# lsblk [händisch ergänzt: File System und Version]
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:5 0 931,5G 0 disk
├─nvme0n1p1 259:6 0 953M 0 part /boot/efi [vfat FAT32]
├─nvme0n1p2 259:7 0 954M 0 part /boot [ext4 1.0]
└─nvme0n1p3 259:8 0 929,6G 0 part [crypto 2]
└─nvme0n1p3_crypt 253:0 0 929,6G 0 crypt / [ext4 1.0]

root@P3U:~# mount | grep nvme0n1p3
/dev/mapper/nvme0n1p3_crypt on / type ext4 (rw,relatime,errors=remount-ro)

Einziger Unterschied zu Deinem File System: hier ist's ein verschluesseltes ext4.

Unverstaendlich fuer mich: das File System ist entschluesselt und gemounted - ABB sollte also eigentlich voellig transparent darauf zugreifen koennen... Tut"s aber nicht :-(

ABB-Portal zeigt nur folgendes:

Es werden nur die beiden unverschlüsselten Partitionen erkannt und gebackup't.

 

[Adama]

Dann scheint sich das anders zu verhalten als bei Windows...

Interessant...

 

[migieger]

Definitiv.
Ich nutze unter Windows Veracrypt und verschlüssele die (eine große) Systempartition damit.
Sobald diese entschlüsselt (und gemounted) ist, kann ABB damit problemlos umgehen...

 

[migieger]

Irgendwann werde ich die vorhandene luks 2 Verschlüsselung in eine luks 1 Verschlüsselung downgraden (soll ohne Datenverlust machbar sein) und schauen was ABB dann meint.

Wenn luks 1 auch nicht geht (womit ich rechne) entferne ich die luks 1 Verschlüsselung (soll auch ohne Datenverlust gehen). ABB sollte dann die Partition erkennen.

Dann probiere ich mal Veracrypt für eine eigene /home (Daten)Partition und bin gespannt wie ABB sich dazu verhält...

Wie schön, schon wieder viele Projekte für verregnete Tage...

...es sei denn hier meldet sich einer und sagt "so und so geht's".

 

[Adama]

Wenigstens kann man sicher sein, dass keine Langeweile aufkommt...

 

[migieger]

Habe bei Synology 'mal ein Ticket geöffnet mit der Frage, ob ABB jemals eine Unterstützung für LUKS verschlüsselte Partitionen erhalten wird...
Mal sehen, was geantwortet wird.

 

[Rotbart]

Wenn ich richtig liege arbeitet die Festplattenverschlüsselung von Synology doch auch mit LUKS und ich kann ja ein komplett Backup einer vollverschlüsselten Station mit ABB machen.Oder irre ich mich da ?

 

[maxblank]

ABB kann meiner Meinung nach nur verschlüsselte Ordner sichern, wenn diese angehängt (also entschlüsselt) sind. Ansonsten sieht ABB diese Freigaben nicht und sichert sie daher auch nicht.

Edit: Oder meinst du die Volume Encryption? Wenn diese entschlüsselt ist, sollte es gehen.

 

[Rotbart]

Ja ich meine Volumenverschlüsselung.

 

[migieger]

Wenn ich richtig liege arbeitet die Festplattenverschlüsselung von Synology doch auch mit LUKS und ich kann ja ein komplett Backup einer vollverschlüsselten Station mit ABB machen.Oder irre ich mich da ?

Meiner Erfahrung nach kann ABB keine entschlüsselten, gemounteten Volumes/Partitionen backupen (siehe Beitrag #5).
ABB sieht nur die nicht verschlüsselten Partitionen...

 

[maxblank]

Bitte nicht die NAS-Sicherung mit ABB und Client-Backups durcheinander würfeln.

 

[migieger]

Schnelle Antwort von Synology: "Leider müssen wir Ihnen mitteilen, dass die von Ihnen angefragte Funktion derzeit nicht unterstützt wird".
Schade...
Damit ist ABB für Linux-Laptops wohl raus (oder man verzichtet auf (LUKS basierte) Verschlüsselung).
Ich mache auf alle Fälle noch den Test mit Veracrypt...

 

[migieger]

Zwischenstand:
Nach Umwandlung der Root-Partition von LUKS2 auf LUKS1 (*):

root@P3U:~# cryptsetup status /dev/mapper/nvme0n1p3_crypt
/dev/mapper/nvme0n1p3_crypt is active and is in use.
type: LUKS1
...

Leider keinerlei Aenderung des Verhaltens von ABB (es werden nur die unverschluesselten Partitionen /boot und /boot/efi erkannt und gebackupt).

Ergo: ABB erkennt nativ mit Linux (LUKS1/2) verschluesselte Partitionen _nicht_

(*) Fuer die Chronik: Umwandlung von LUKS2 zu LUKS1 Verschluesselung wie folgt:

1. Booten von Debian 12 Live USB Stick
2. cryptsetup luksChangeKey --pbkdf pbkdf2 /dev/nvme0n1p3
   Abfrage nach LUKS2-Passphrase
   Eingabe 2x der LUKS1-Passphrase (habe dieselbe genommen)
3. cryptsetup convert --type luks1 /dev/nvme0n1p3
   Abfrage Are you sure
   Antwort YES
4. Reboot (ohne Probleme)

Es waren keinerlei Aenderungen fuer grub, initramfs, fstab etc notwendig.

 

[migieger]

Naechster Zwischenstand:

Nach Aufheben der Verschluesselung (*) erkennt ABB die nun entschluesselte Root-Partition einwandfrei...

(*) Fuer die Chronik: Aufheben der Verschluesselung wie folgt:

1. Booten von Debian 12 Live USB Stick
2. cryptsetup reencrypt --decrypt /dev/nvme0n1p3
   Abfrage nach Passphrase
   23 Min spaeter waren knapp 1TB entschluesselt
3. mount /dev/nvme0n1p3 /mnt
   chroot /mnt
   rm /etc/crypttab
   Anpassen der /etc/fstab von "/dev/mapper/nvme0n1p3_crypt /" auf "/dev/nvme0n1p3 /"
4. Reboot (ohne Probleme)

 

[migieger]

So, jetzt auch mit Veracrypt verschlüsselter Partition probiert. Vorab: geht auch nicht :-(

Veracrypt hängt die Partition nvme0n1p4 (ähnlich wie LUKS) als /dev/mapper/veracrypt6 ins Dateisystem ein. Das ist (wie bei LUKS) entschlüsselt und gemounted - also für das Dateisystem völlig transparent.

Aber ABB will nicht. Es erkennt diese Partition einfach nicht (wie LUKS).

root@P3U:~# lsblk --fs
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat FAT32 7B82-C0E0 929,2M 2% /boot/efi
├─nvme0n1p2 ext4 1.0 293f5184-fe1e-42b6-b94b-eb986add0752 622,6M 25% /boot
├─nvme0n1p3 ext4 1.0 2d35c7c9-34cd-4e91-a473-9840d8efc998 733,4G 12% /
└─nvme0n1p4
└─veracrypt6 ext4 1.0 7afc5b35-3409-48e2-a674-61cc07497242 29,7G 0% /media/veracrypt6

root@P3U:~# mount | grep veracrypt
veracrypt on /tmp/.veracrypt_aux_mnt1 type fuse.veracrypt (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
/dev/mapper/veracrypt6 on /media/veracrypt6 type ext4 (rw,relatime)

Insges. wirklich schade, weil mir ABB mit seinem unbeaufsichtigten Backup wirklich gefällt.
Für Server/Desktops daheim wäre die Kröte (keine Verschlüsselung) evtl. noch zu schlucken. Für Laptops, die auch mal verloren gehen können, ist die Kröte aber zu groß. Dh, entweder kein ABB oder kein Linux.
Besonders bitter wird die Pille, weil ABB für die eigene Verschlüsselung LUKS nutzt...