Hallo,
ich versuche derzeit ein Backup eines Containers auf dem gleichen Host wieder einzuspielen, auf dem es auch erstellt wurde. Leider schlägt dies fehl:
Der Container existiert auf dem Proxmox Host nicht mehr und würde durch das Backup neu angelegt werden. Der Container war zuvor unprivileged und soll es auch nach dem Restore bleiben, beim Restore habe ich bei "Privilege Level" "From Backup" ausgewählt.
Der Container lief zuvor auf einer ZFS storage, Restore auf eben jene als auch auf eine BTRFS Storage schlägt mit der gleichen Meldung fehl.
Ich verwende Proxmox VE 8.2.4 mit
Durch googlen habe ich herausgefunden, dass ich nicht der Einzige mit dem Problem bin, doch leider hat bisher niemand eine Lösung für das Problem gefunden:
- https://www.reddit.com/r/Proxmox/comments/1bh2z17/lxc_restore_from_pbs/
- https://forum.proxmox.com/threads/unable-to-restore-lxc-backup-acl-invalid.119324/ (hier wurde das Problem durch Entfernen der ACL umgangen, dies ist für mich allerdings keine Option, da der Container nur noch als Backup existiert und ich daher keine neuen Backups ohne die problematischen ACL anlegen kann)
- https://forum.proxmox.com/threads/failed-to-apply-acls.86885/ (hier hat ein update des
- https://forum.proxmox.com/threads/restore-dump-nicht-möglich.103565/ (Hier ein ähnliches Problem, allerdings mit gewöhnlichen tar backups statt PBS. Ein Fix soll hier in tar 1.35 enthalten sein. Habe ich installiert, macht keinen unterschied. Es scheint so als würde
Im letzten dieser Posts werden die ACL der problematischen Datei mit folgendem
Also habe ich mir das Verzeichnis
ACLs sind hier keine vorhanden, es ist allerdings möglich, dass die ACLs während dem On-the-fly-archivieren als
Statt einerDaher sehe ich derzeit keine Möglichkeit das Backup einfach zu mounten um die ACLs zu untersuchen. Gibt es eine Möglichkeit, dies zu tun?
Nevermind, der
(restore-temp ist die Gruppe, die ich für GID 984 testweise auf dem Host angelegt habe)
Abgesehen davon scheinen auch hier keine besonderen ACL vorhanden zu sein.
Nun weiß ich wirklich nicht weiter. Hat jemand noch eine Idee? Für jede Hilfe bin ich sehr dankbar! Derzeit sitze ich auf 18 Backups, die allesamt nutzlos sind :'D
EDIT: Wie erwartet hat das Erstellen einer Gruppe mit GID 984 auf dem Host keinen Unterschied gemacht, Restore ist trotzdem wieder fehlgeschlagen. Ich habe Restore zwischenzeitlich auch mit einem kleineren Container getestet, dessen Restore keine 8h dauert. Auch dieser schlägt mit dem gleichen Fehler fehl, also können wir nun immerhin schneller testen.
ich versuche derzeit ein Backup eines Containers auf dem gleichen Host wieder einzuspielen, auf dem es auch erstellt wurde. Leider schlägt dies fehl:
Code:
recovering backed-up configuration from 'roman:backup/ct/102/2024-09-30T00:16:20Z'
Using encryption key from file descriptor..
Fingerprint: ea:19:7b:48:f2:b3:a5:27
Creating filesystem with 131072000 4k blocks and 32768000 inodes
Filesystem UUID: f8fd12b8-0e4c-4cab-812c-e170a95438da
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: c7d6f1df-117d-467d-9f8c-7d33b5383b5a
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
restoring 'roman:backup/ct/102/2024-09-30T00:16:20Z' now..
Using encryption key from file descriptor..
Fingerprint: ea:19:7b:48:f2:b3:a5:27
Error: error extracting archive - encountered unexpected error during extraction: error at entry "system.journal": failed to extract file: failed to apply acls: Error while restoring ACL - ACL invalid
TASK ERROR: unable to restore CT 102 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=encrypt' '--keyfd=13' ct/102/2024-09-30T00:16:20Z root.pxar /var/lib/lxc/102/rootfs --allow-existing-dirs --repository root@pam@my.pbs.domain:main' failed: exit code 255Der Container existiert auf dem Proxmox Host nicht mehr und würde durch das Backup neu angelegt werden. Der Container war zuvor unprivileged und soll es auch nach dem Restore bleiben, beim Restore habe ich bei "Privilege Level" "From Backup" ausgewählt.
Der Container lief zuvor auf einer ZFS storage, Restore auf eben jene als auch auf eine BTRFS Storage schlägt mit der gleichen Meldung fehl.
Ich verwende Proxmox VE 8.2.4 mit
proxmox-backup-client version 3.2.4 und PBS 3.2-7.Durch googlen habe ich herausgefunden, dass ich nicht der Einzige mit dem Problem bin, doch leider hat bisher niemand eine Lösung für das Problem gefunden:
- https://www.reddit.com/r/Proxmox/comments/1bh2z17/lxc_restore_from_pbs/
- https://forum.proxmox.com/threads/unable-to-restore-lxc-backup-acl-invalid.119324/ (hier wurde das Problem durch Entfernen der ACL umgangen, dies ist für mich allerdings keine Option, da der Container nur noch als Backup existiert und ich daher keine neuen Backups ohne die problematischen ACL anlegen kann)
- https://forum.proxmox.com/threads/failed-to-apply-acls.86885/ (hier hat ein update des
proxmox-backup-client das Problem gelöst, ich nutze allerdings bereits die neuste version)- https://forum.proxmox.com/threads/restore-dump-nicht-möglich.103565/ (Hier ein ähnliches Problem, allerdings mit gewöhnlichen tar backups statt PBS. Ein Fix soll hier in tar 1.35 enthalten sein. Habe ich installiert, macht keinen unterschied. Es scheint so als würde
proxmox-backup-client tar ohnehin nicht verwenden.)Im letzten dieser Posts werden die ACL der problematischen Datei mit folgendem
tar Befehl untersucht:
Code:
tar -t -vv --acls -f path/to/archive.tar path/to/fileAlso habe ich mir das Verzeichnis
/var/log/journal/30e67dbb3d304b198d2c59c137e73a13, welches die Datei system.journal enthält, via das Proxmox VE Webinterface als .tar.zst heruntergeladen und mir mit obigem Befehl die ACL der Datei angesehen:
Code:
$ tar -t -vv --acls -f Downloads/30e67dbb3d304b198d2c59c137e73a13.tar.zst 30e67dbb3d304b198d2c59c137e73a13/system.journal
-rw-r----- 0/984 33554432 2024-09-30 02:16 30e67dbb3d304b198d2c59c137e73a13/system.journalACLs sind hier keine vorhanden, es ist allerdings möglich, dass die ACLs während dem On-the-fly-archivieren als
.tar.zst gestripped werden. Auch wenn GIDs keine ACLs sind, habe ich die Gruppe 984 mal auf dem Proxmox VE Host angelegt, wie es im letzten verlinkten Post für ACLs als Workaround empfohlen wird. Ich gehe nicht davon aus, dass es einen Unterschied macht, habe den Restore aber nun mal wieder gestartet. Restore braucht 8h bis er failed, irgendwas muss man ja probieren.Statt einer
root.pxar wie bei tar backups gibt es beim PBS nur eine root.pxar.didx, welche lediglich den Chunk Index enthält. Nevermind, der
proxmox-backup-client kann das! Also grad mal das Backup gemounted und die ACL angesehen:
Code:
$ mkdir temp
$ proxmox-backup-client mount ct/102/2024-09-30T00:16:20Z root.pxar temp --repository root@pam@my.pbs.domain:main --keyfile /etc/pve/priv/storage/roman.enc
Password for "root@pam":
Encryption key file: '"/etc/pve/priv/storage/roman.enc"'
Encryption key fingerprint: 'ea:19:7b:48:f2:b3:a5:27'
storing login ticket failed: $XDG_RUNTIME_DIR must be set
FUSE library version: 3.14.0
$ getfacl temp/var/log/journal/30e67dbb3d304b198d2c59c137e73a13/system.journal
# file: temp/var/log/journal/30e67dbb3d304b198d2c59c137e73a13/system.journal
# owner: root
# group: restore-temp
user::rw-
group::r--
other::---(restore-temp ist die Gruppe, die ich für GID 984 testweise auf dem Host angelegt habe)
Abgesehen davon scheinen auch hier keine besonderen ACL vorhanden zu sein.
Nun weiß ich wirklich nicht weiter. Hat jemand noch eine Idee? Für jede Hilfe bin ich sehr dankbar! Derzeit sitze ich auf 18 Backups, die allesamt nutzlos sind :'D
EDIT: Wie erwartet hat das Erstellen einer Gruppe mit GID 984 auf dem Host keinen Unterschied gemacht, Restore ist trotzdem wieder fehlgeschlagen. Ich habe Restore zwischenzeitlich auch mit einem kleineren Container getestet, dessen Restore keine 8h dauert. Auch dieser schlägt mit dem gleichen Fehler fehl, also können wir nun immerhin schneller testen.
Last edited:
mit der catalog shell sollte ein selective restore aber moeglich sein (oder vielleicht mehr details liefern).