lxc Container exclude mount point / zweite hdd

[maxprox]

Hallo,
eine Anfängerfrage zu LXC Containern:
Ich habe ein Proxmox, 6.3-6, auf dem zwei LXC Container laufen, ein Proxmox Backup Server auf Debian installiert, ein zweites Debian für URBackup.
(OT: wer zfs rocks kennt, kennt gorb das Setup ;-)
Der Backup-Mini Server hat eine SSD auf der sowohl das Proxmox, als auch die Container installiert sind.
Zusätzlich läuft eine 4 TB NAS Festplatte, von der jeder Container LVM-thin mäßig eine große virtuelle Disk, als Moint Point zugewiesen bekommt.
Folgendermaßen sieht das innerhalb des Containers aus:

19:31root@pbs~# df -hT
Filesystem                              Type   Size  Used Avail Use% Mounted on
/dev/mapper/pve-vm--100--disk--0        ext4    14G  2.3G   11G  18% /
/dev/mapper/thinpool4t-vm--100--disk--0 ext4   2.5T   17G  2.4T   1% /srv/pbspool

Von den Containern wurden vzdumps erzeugt, zB. per:

vzdump 100 --mode stop --compress zstd --dumpdir /srv/dumpool/

Dabei WICHTIG: die zweite Festplatte des Containers, in Proxmox der zugewiesene Mount Point, hat die Option "Backup = deaktiviert"
Natürlich wird bei diesem vzdump die zweite Festplatte NICHT mitgesichert und soll nicht mitgesichert werden.

PROBLEM:
Zu Testzwecken habe ich das letzte vzdump des Container heute wieder hergestellt.

pct restore 100 /var/lib/vz/dump/vzdump-lxc-100-2021_04_05-14_51_48.tar.zst --storage local-lvm

Das war es dann mit allen bisherigen Sicherungen. Beim Wiederherstellen wurde vom Container ALLES gelöscht, also auch die zweite Festplatte = Moint Point und somit auch alle darauf liegenden Daten. Die aber im vzdump gar nicht enthalten waren... :-(
siehe Ausgabe unten.

Frage:
Wie sieht hier die sauber funktionierende Lösung aus?
Also die, bei der es möglich ist, nur das System bzw. die virtuelle Systemfestplatte zu sichern und wieder herzustellen, ohne die virtuelle zweite Festplatte zu "removen", sondern die "alte" zweite Festplatte mit allen darauf befindlichen Daten wieder per Moint Point in das wiederhergestellte System einbinden zu können?

Grüße,
maxprox

## pct restore Ausgabe:

recovering backed-up configuration from 'local:backup/vzdump-lxc-100-2021_04_05-14_51_48.tar.zst'
  Logical volume "vm-100-disk-1" created.
Creating filesystem with 3670016 4k blocks and 917504 inodes
Filesystem UUID: eb30a014-899d-4c4d-9a9c-b97c33d4fdeb
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
  WARNING: You have not turned on protection against thin pools running out of space.
  WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.
  Logical volume "vm-100-disk-2" created.
  WARNING: Sum of all thin volume sizes (<2.55 TiB) exceeds the size of thin pool pve/data and the size of whole volume group (<223.07 GiB).
Creating filesystem with 672661504 4k blocks and 168165376 inodes
Filesystem UUID: 38039d89-86cf-4098-a675-9a4e700d3289
Superblock backups stored on blocks:
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
    102400000, 214990848, 512000000, 550731776, 644972544
  Logical volume "vm-100-disk-0" successfully removed
  Logical volume "vm-100-disk-0" successfully removed
restoring 'local:backup/vzdump-lxc-100-2021_04_05-14_51_48.tar.zst' now..
extracting archive '/var/lib/vz/dump/vzdump-lxc-100-2021_04_05-14_51_48.tar.zst'
tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted
Total bytes read: 2366556160 (2.3GiB, 297MiB/s)
tar: Exiting with failure status due to previous errors
  Logical volume "vm-100-disk-1" successfully removed
  Logical volume "vm-100-disk-2" successfully removed
TASK ERROR: unable to restore CT 100 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - --zstd --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' -C /var/lib/lxc/100/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2

 

[maxprox]

Jetzt habe ich weitere Wiederherstellungsversuche gestartet:
- die Backup Option der zweiten virtuellen Disk war von Anfang an aus (disabled)
- zusätzlich habe ich beim vzdump per "--exclude-path /srv/mp0" den Mount Point ausgeschlossen

vzdump 222 --mode stop --compress zstd --exclude-path /srv/mp0

Trotzdem wird beim Wiederherstellen:

pct restore 222 /var/lib/vz/dump/vzdump-lxc-222-2021_04_08-10_ --force --storage local-lvm

die zweite virtuelle Festplatte: vm-222-disk-0 immer zuerst gelöscht und dann leer wieder neu angelegt
Diese "vm-222-disk-0", ein Logical volume, entspricht dem Mount Point "/srv/mp0"

    ...
  Logical volume "vm-222-disk-0" successfully removed
  Logical volume "vm-222-disk-0" successfully removed
  ...

(Beide Logical volumes haben den selben Namen, weil sie auf dem Hostsystem auf zwei unterschiedlichen Festplatten und zwei unterschiedlichen Volume groups liegen: 1: pve, 2: thinpool4t)

WORKOROUND:
---------------------------
Den Workaround, den ich gefunden habe, ist vor dem Wiederherstellen, das Logical volume zu sichern, zB durch Umbenennen:

lvrename /dev/thinpool4t/vm-222-disk-0 /dev/thinpool4t/vm-222-disk-0bak

vzdump erstellen wie oben:

vzdump 222 --mode stop --compress zstd --exclude-path /srv/mp0

Zuvor aus der VMID.conf die Zeile des zusätzlichen Mount Points (zweite virtuelle disk) raus nehmen.
Dann die Wiederherstellung zu einer neuen VMID, also eines noch nicht existierenden LXC Containers (222 zu 333):

pct restore 333 /var/lib/vz/dump/vzdump-lxc-222-2021_04_08-10_31_48.tar.zst --storage local-lvm

Das Logical volume wieder umbenennen, jetzt passend zum neuen Container:

lvrename /dev/thinpool4t/vm-222-disk-0ak /dev/thinpool4t/vm-333-disk-0

Zum Schluss die entsprechende Zeile für den Mount Point dieses Logical volume in die neue VMID.conf manuell hinzufügen:

12:22root@backuprox~# pct config 333
arch: amd64
cores: 4
hostname: TEST
memory: 2048
## ++ folgende Zeile manuell hinzugefügt: ++ ##
mp0: thinpool4t:vm-333-disk-0,mp=/srv/mp0,replicate=0,size=8G
nameserver: 172.21.8.200
net0: name=eth0,bridge=vmbr0,firewall=1,gw=172.21.8.1,hwaddr=E2:E0:CB:CC:4F:3E,ip=172.21.8.91/24,type=veth
ostype: debian
rootfs: local-lvm:vm-333-disk-0,replicate=0,size=8G
searchdomain: frog.llan
swap: 2048

somit habe ich jetzt einen funktionierend getesteten Workaround, für den Zweck, Falls die SSD des Hostsystems kaputt geht und ich das System wieder herstellen muss. Damit kann ich zum einen bequem auf die gesicherten Daten wieder zugreifen und fast noch wichtiger:
ich kann anschließend konsistent mit den Backups da fortsetzen, wo es vor dem Ausfall aufgehört hat.

Falls jemand tieferen Einblick hat und durchschaut ob ich durch diesen händischen Workaround, Proxmox Einstellungen, zB bezüglich des storage, "inkonsistent mache", dann wäre ich für eine Rückmeldung dankbar

Grüße,
maxprox

 

[maxprox]

WORKOROUND:
---------------------------
Den Workaround, den ich gefunden habe, ist vor dem Wiederherstellen, das Logical volume zu sichern, zB durch Umbenennen:

NEIN, kann man vergessen.
Bitte nicht nach machen. Das funktioniert alles nicht wirklich. Mit dem von mir vorgeschlagenen (nicht funktionierenden) Workaround sind zwar anschließend noch alle Daten da. Beim neuen mounten des umbenannten logical volumes greift aber das problem mit den bind-mounts und dem ID-mapping: siehe:
https://pve.proxmox.com/wiki/Unprivileged_LXC_containers
Somit stimmen die Rechte nicht mehr und die lassen sich wie oben beschrieben auch nicht mehr so einfach korrigieren.

=> Resultat für mich zZ gibt es keine sinnvolle Wiederherstellungsmöglichkeit für den kompletten Proxmox-Backup-Server in Form eines LXC Containers.
Hier ist es schneller und einfacher nach dem Löschen des Datastores
proxmox-backup-manager datastore remove store1
auf dem PVE Host mit lvremove das logical volume löschen und auf dem zu sichernden PVE das PBS-Backup Storage wieder entfernen, um dann alles wieder neue zu machen ....

 

[Fossi]

Mit aktiviertem Haken "Keine Replikation" sollte die Wiederherstellung ohne Mountpiont erfolgen - zumindest ist das bei den VMs so.

 

[maxprox]

Mit aktiviertem Haken "Keine Replikation" sollte die Wiederherstellung ohne Mountpiont erfolgen - zumindest ist das bei den VMs so.

Dank dir für den Hinweis, das müsste ich noch mal versuchen, kann sein dass ich bei diesen ersten Tests übersehen habe die Replikation raus zu nehmen...
Zur Zeit habe ich noch nicht DIE (für mich) passende Lösung zur Wiederherstellung des PromoxBackupServers, der bei mir als LXC Container läuft gefunden. Dabei halte ich in meinen "keinen" Umgebungen ein Backupsystem mit Raid System für zu "teuer". Der Ausfall selber wäre ja erst mal völlig unkritisch ... usw.
grüße