Restore von CT Backup funktioniert nicht

Nicht nur die Anbieter, sondern (vor allen) die Betreiber. Auf der Arbeit haben wir mittlerweile neben den Ubuntu-Mirror bestimmt 20 3rd-party-Repositories, weil irgendwelche Entwickler unbedingt die neueste Version von docker oder ihrer Lieblingsdatenbank verwenden wollen. Sobald da ein Upgrade einen breaking change reinbringt, hat man dann das Vergnügen. Da wäre mir die Variante mit den Containern doch deutlich lieber: Damit machen die Entwickler nur ihre eigene Spielwiese kaputt, nicht die vom Rest.
Je mehr unixoide Clients virtualisiert sind, desto mehr Charme entwickelt eine Containerisierung.
Aber auch heutzutage sind leider 95% aller virtualisierten Umgebungen immer noch nicht unixoid, sofern wir nicht von Hyperscalern sprechen. Damit ist ist meistens schon Essig mit Containern.

Zentrale Systeme hingegen, sind in meinem Umfeld fast ausschließlich unixoid, aber trotzdem alle virtualisiert. Da fummelt auch keine umtriebige Horde von Entwicklern drauf rum. Also wieder kein Grund diese zu containerisieren statt zu virtualisieren.

[OT]
Beim Zugriff auf unixoide Desktop-Clients nervt z.B. der Remotezugriff an sich viel mehr.
Entweder man nutzt extrem nerviges VNC oder schlägt sich mit RDP rum.
Letzteres funktioniert prinzipiell zwar sehr gut, war aber schon immer fummelig. Seit Aussterben von X11 ist es in letzter Zeit jedoch kaum mehr nutzbar. Ich hoffe diese Entwicklung ändert alsbald die Richtung.
Der Zugriff auf die gottgleiche, beste aller Zeiten Plattform des Weltmarktführers funktioniert ganz gut.
Von Unterstützung aufstrebender Plattformen wie ARM etc. will ich gar nicht erst anfangen.
/[OT]

Ich will Container keinesfalls verteufeln. Sie machen meine reale Umgebung nur nicht effizienter.

Wollte ich nur mal darlegen, damit kein falscher Eindruck meines Standpunkts bzgl. Containern entsteht.

P.S.:
Bei Containern ist auch immer die Frage, welche Geschmacksrichtung es denn sein darf.
Parallels, LXC, Kubertnetes, Docker, Snap, Flatpak etc.?
Meistens gibt es die duften Dinger immer nur in einem Format, dass mein Host gerade nicht unterstützt.
Da entwickelte sich in meinen Augen unfassbar viel in die falsche Richtung.
Diese absurde Vielfalt gibt es bei KVM nicht.
 
Last edited:
Die aktive Diskussionskultur im Thread kann man auf jeden Fall nicht abstreiten. Die meisten Beträge haben jedoch leider sehr wenig mit den originalen Fragen von mir oder mit diesbezüglichen Klärungsversuchen dazu zu tun.
Falls weiterhin der Bedarf besteht die Unterschiede oder Feinheiten zwischen CT und VM zu diskutieren, dann würde ich mir stark wünschen, dass dafür ein eigenen Thread aufgemacht wird.
Vielen Dank!


Hi Johannes S,

ich habe jetzt zwei Container erstellt und versuche ein Minimal Viable Container zu erstellen, damit ich das Problem besser nachstellen bzw. dokumentieren kann.
In den ersten paar Tests konnte ich das Verhalten bisher leider noch nicht nachstellen. Die beiden Container aber genau 1:1 herstellen wie der original CT 110 wird ein bisschen brauchen.

Bezüglich der OpenVPN bzw. Wireguard Frage verstehe ich nicht ganz was genau das mit der Fragenstellung zu tun hat. Ich habe weder ein Problem noch Schmerzen beim Aufsetzen oder Handeln von OpenVPN oder Wireguard. Mein Problem ist der unerfolgreiche Restore eines CT in Proxmox. Was genau übersehe ich hier aus deiner Sicht?
 
Last edited:
Die aktive Diskussionskultur im Thread kann man auf jeden Fall nicht abstreiten. Die meisten Beträge haben jedoch leider sehr wenig mit den originalen Fragen von mir oder mit diesbezüglichen Klärungsversuchen dazu zu tun.
Falls weiterhin der Bedarf besteht die Unterschiede oder Feinheiten zwischen CT und VM zu diskutieren, dann würde ich mir stark wünschen, dass dafür ein eigenen Thread aufgemacht wird.
Vielen Dank!


Hi Johannes S,

ich habe jetzt zwei Container erstellt und versuche ein Minimal Viable Container zu erstellen, damit ich das Problem besser nachstellen bzw. dokumentieren kann.
In den ersten paar Tests konnte ich das Verhalten bisher leider noch nicht nachstellen. Die beiden Container aber genau 1:1 herstellen wie der original CT 110 wird ein bisschen brauchen.

Bezüglich der OpenVPN bzw. Wireguard Frage verstehe ich nicht ganz was genau das mit der Fragenstellung zu tun hat. Ich habe weder ein Problem noch Schmerzen beim Aufsetzen oder Handeln von OpenVPN oder Wireguard. Mein Problem ist der unerfolgreiche Restore eines CT in Proxmox. Was genau übersehe ich hier aus deiner Sicht?
Gerade an den hier entflammten Diskussionen könntest du schon profitieren.
Du rufst aber eher mit "ich will, ich will" nach Mami.
Zusätzlich lieferst du unterirdische und willenlose "Informationen", die keine Sau reliabel beantworten kann.
Vielleicht hat irgendwer noch den Nerv, dir aus dem Bettchen zu helfen.
Das Ganze offenbar noch auf deinem persönlichen Spielplatz.
Dabei wünsche ich Dir Erfolg.
 
In den ersten paar Tests konnte ich das Verhalten bisher leider noch nicht nachstellen. Die beiden Container aber genau 1:1 herstellen wie der original CT 110 wird ein bisschen brauchen.

Hmpf, schade. Ich war halt am Überlegen, ob es vielleicht aus unklaren Gründen irgendeine Besonderheit beim piVPN-Setup gibt, die dann beim Restore den Fehler triggert. Das kann man dann wohl ausschließen.

Bezüglich der OpenVPN bzw. Wireguard Frage verstehe ich nicht ganz was genau das mit der Fragenstellung zu tun hat. Ich habe weder ein Problem noch Schmerzen beim Aufsetzen oder Handeln von OpenVPN oder Wireguard. Mein Problem ist der unerfolgreiche Restore eines CT in Proxmox. Was genau übersehe ich hier aus deiner Sicht?
Vergiss es, das liegt daran, dass ich in der Nebendebatte den Faden verloren habe, was eigentlich dein Problem war ;)
 
Moin,
sorry für die späte Antwort. Ich habe mir den stacktrace jetzt erst angeschaut.

Code:
1893 [pid 16113] openat(AT_FDCWD, "/run/user/0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 EACCES (Permission denied)                                                               
1894 [pid 16113] ioctl(0, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}     ) = 0
1895 [pid 16113] ioctl(0, TCGETS, {c_iflag=ICRNL|IXON, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|OPOST|ONLCR, c_cflag=B38400|CS8|CREAD, c_lflag=ISIG|ICANON|ECHO|ECHOE|ECHOK|IEXTEN|ECHOCTL|ECHOKE, ...}     ) = 0                                                                                                           
1896 [pid 16113] ioctl(1, TCGETS, 0x7ffd32f897b0) = -1 ENOTTY (Inappropriate ioctl for device)

Er beschwert sich da ja an der Stelle, dass er nicht auf "/run/user/0" zugreifen kann und an anderer Stelle, das er nicht auf /var/log/journal zugreifen kann. Mit dem lxc-usernsexec sollte er seine priviledges auch bereits direkt am Anfang droppen und dann fehlen ihm ggf. Rechte.
Das S tarten als privilegierter Container, wie bereits vorgeschlagen, hätte das eigentlich fixen können.

Allerdings gibt es ja in dem Container ja noch den VPN-User - theoretisch ist die Nutzung kein wirklicher Sicherheitsgewinn, falls dieser dazu verwendet wird um Prozesse mit separierten Berechtigungen zu starten. Denn die Verwendung eines unprivilegierten Containers, sorgt mittels des UID/GID mappings ja bereits dafür das den Prozessen root berechtigungen simuliert werden, während sie auf dem eigentlichen Container Host in einem anderen Usercontext laufen.

Du hattest ja geschrieben, dass das Journalctl erst nachträglich in Verwendung genommen wurde.
Hast du noch einen Backupstand von davor? /var/log/journal hat nämlich erweiterte Filesystem ACLs und ich bin mir nicht sicher,
ob das kompatibel ist mit der Konfiguration des LXC UID/GID Mappings.

Ist die Fehlermeldung bzw. der Stacktrace, wenn der als Privilegierter Container wiederhergestellt wird, dieselbe?

BG, Lucas
 
Entschuldigt bitte die späte Antwort, aber ich kann leider nicht jeden Tag Zeit für Proxmox und das Forum aufwenden.

Hi CoolTux,

der Befehl für den Restore mit den ignore Errors hat leider keine Veränderung gezeigt. Egal ob "normal" oder mit fixen Privilegien:
Code:
root@proxmox:~# pct restore 110 pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z  --ignore-unpack-errors 1 --rootfs local-lvm:8
recovering backed-up configuration from 'pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z'
  Logical volume "vm-110-disk-0" created.
  Logical volume pve/vm-110-disk-0 changed.
Creating filesystem with 2097152 4k blocks and 524288 inodes
Filesystem UUID: b77a594c-0fe8-4627-be25-85933a03ebb1
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
restoring 'pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z' now..
Warning: "/var/log/journal" - ACL invalid, attempting restore anyway..
Error: error extracting archive - encountered unexpected error during extraction: error at "/var/log/journal": error at entry "": failed to leave directory: failed to apply directory metadata: error at "/var/log/journal": failed to apply acls: EINVAL: Invalid argument
  Logical volume "vm-110-disk-0" successfully removed.
unable to restore CT 110 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-04-17T01:00:25Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --ignore-extract-device-errors --repository proxmox@pbs@192.168.1.191:backup-local' failed: exit code 255
root@proxmox:~# pct restore 110 pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z  --ignore-unpack-errors 1 --rootfs local-lvm:8 --unprivileged 0
recovering backed-up configuration from 'pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z'
  Logical volume "vm-110-disk-0" created.
  Logical volume pve/vm-110-disk-0 changed.
Creating filesystem with 2097152 4k blocks and 524288 inodes
Filesystem UUID: 4ec39ec0-6b51-4d89-aaa0-0b4a3605b22b
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
restoring 'pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z' now..
Warning: "/var/log/journal" - ACL invalid, attempting restore anyway..
Error: error extracting archive - encountered unexpected error during extraction: error at "/var/log/journal": error at entry "": failed to leave directory: failed to apply directory metadata: error at "/var/log/journal": failed to apply acls: EINVAL: Invalid argument
  Logical volume "vm-110-disk-0" successfully removed.
unable to restore CT 110 - command '/usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-04-17T01:00:25Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --ignore-extract-device-errors --repository proxmox@pbs@192.168.1.191:backup-local' failed: exit code 255
root@proxmox:~# pct restore 110 pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z  --ignore-unpack-errors 1 --rootfs local-lvm:8 --unprivileged 1
recovering backed-up configuration from 'pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z'
  Logical volume "vm-110-disk-0" created.
  Logical volume pve/vm-110-disk-0 changed.
Creating filesystem with 2097152 4k blocks and 524288 inodes
Filesystem UUID: 030aea3c-7e29-4b91-ab1c-2411d5bb565b
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
restoring 'pbs-backup-local:backup/ct/110/2026-04-17T01:00:25Z' now..
Warning: "/var/log/journal" - ACL invalid, attempting restore anyway..
Error: error extracting archive - encountered unexpected error during extraction: error at "/var/log/journal": error at entry "": failed to leave directory: failed to apply directory metadata: error at "/var/log/journal": failed to apply acls: EINVAL: Invalid argument
  Logical volume "vm-110-disk-0" successfully removed.
unable to restore CT 110 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-04-17T01:00:25Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --ignore-extract-device-errors --repository proxmox@pbs@192.168.1.191:backup-local' failed: exit code 255


bl1mp bezüglich deiner Fragen:
Ja, ich habe Backupstande vor der Journal Logging Umstellung. Diese habe ich auch schon versucht zu restoren (mit allen Kombinationen der Privilegien), aber das hat leider keine Veränderung gezeigt.

Den zweiten Teil der Frage habe ich nicht ganz verstanden und meine Auslegungen der Frage ist entweder:
1. Gibt es einen Unterschied im StackTrace zwischen
Code:
strace -f lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-04-17T01:00:25Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --repository proxmox@pbs@192.168.1.191:backup-local
und
Code:
strace -f lxc-usernsexec -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-04-17T01:00:25Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --repository proxmox@pbs@192.168.1.191:backup-local
Die Antwort ist ich bekomme das selbe Fehlerverhalten, aber eine höhere PID Nummer.

2. Gibt es einen Unterschied in StackTracen zwischen den verschiedenen Versionen (mit Journal Logging und ohne)
CODE]strace -f lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-04-17T01:00:25Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --repository proxmox@pbs@192.168.1.191:backup-local[/CODE] und
Code:
strace -f lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/110/2026-02-22T02:00:24Z root.pxar /var/lib/lxc/110/rootfs --allow-existing-dirs --repository proxmox@pbs@192.168.1.191:backup-local
Leider tritt auch hier das selbe Fehlerverhalten auf, mit einer höheren PID Nummer.

Habe ich dich falsch verstanden oder die Frage falsch interpretiert?
 
Gut, da ich das Fehlerverhalten auch nicht nachstellen kann, obwohl ich es jetzt schon auf verschiedenen Weisen versucht habe, mache ich das Backup nun händisch. Falls jemand in der Zukunft das auch machen muss, dann hier eine kurze Anleitung:

1. Erstellen von neuen Container mit der neuen ID z.B. 111 sowie falls notwending Installation der notwendigen Programme
2. Anlegen von einen Ordner für den Restore
mkdir /mnt/restore-ct-110/
3. Mounten des Backups in PVE Shell
proxmox-backup-client mount ct/110/2026-04-17T01:00:25Z root.pxar /mnt/restore-ct-110/ --repository proxmox@pbs @192.168.1.191:backup-local
ct/110/2026-04-17T01:00:25Z ist der Name des Backups
/mnt/restore-ct-110/ ist der erstelle Ordnername von Schritt 2
-repository proxmox@pbs @192.168.1.191:backup-local ct/110/2026-04-17T01:00:25Z
ist wichtig, da der PBS remote ist proxmox@pbs ist der Nutzer, der auf das Backup zugreifen soll und der @192.... Part ist der Server sowie das Backup auf diesem Server
4. Mounten von den Container 111
pct mount 111
5. Kopieren der Ordner auf den neuen Container
Heirbei ist wichtig, dass man weiß wie Rsync funktioniert! --delete löscht auf der rechten Seite (neuer Container) Dateien, die im Backup 110 nicht vorkommen. Das kann sehr gefährlich sein!
rsync -avv --delete /mnt/restore-ct-110/etc/openvpn/ /var/lib/lxc/111/rootfs/etc/openvpn/
rsync -avv --delete /mnt/restore-ct-110/etc/pivpn/ /var/lib/lxc/111/rootfs/etc/pivpn/
6. Setzen der richtigen Berechtigungen
chown -R 100000:100000 /var/lib/lxc/111/rootfs/etc/openvpn/
chown -R 100000:100000 /var/lib/lxc/111/rootfs/etc/pivpn/
7. Nachher wieder aufräumen
umount /mnt/restore-ct-110
Unmounted das Backup des Containers
pct unmount 111
Unmounted den neuen Container
rm -rf /mnt/restore-ct-110
Löscht den neuen Container von Schritt 2

PS: Nicht vergessen, ein Backup, dass nicht mal ausprobiert worden ist, ob es funktioniert, ich kein Backup. Daher beim ersten Backup ein Restore mit einer anderen ID machen um es zu überprüfen!
 
Last edited:
Das nenne ich mal abenteuerliches Konstrukt.
Viel einfacher und gar nicht so unüblich wäre eine zum PBS parallele RAW-Sicherung.
Wie prüfst du eigentlich, ob deine Rücksicherung nicht nur ohne Fehler zurückkopiert wurde, sondern auch startfähig und sogar lauffähig ist?
 
Last edited:
  • Like
Reactions: Johannes S
Hallo TErxleben,

wie man ein teilweises Restore (z.B. wie meine Schritte im vorigen Post) überprüft ist eine sehr gute Frage.

In diesem Fall ist es eine Mischung aus:

1. Bevor man ein Restore beginnt macht man ein Backup und prüft die Restorefähigkeit dessen mit einer anderen ID

2. Durch mein Wissen über OpenVPN und PiVPN weiß ich sehr gut wo welche Dinge stehen und wofür diese benötigt werden. Wenn man dieses Wissen nicht haben sollte, dann kann man sich auch dieses teilweise mit die Container Backups herleiten. Ein Beispiel ist ein Backup herzunehmen, wo weder OpenVPN noch PiVPN auf der Maschine installiert ist und mit einem Backup danach zu vergleichen. Die Dateien, die geändert worden sind, sind dann ein sehr guter Anfang das Wissen aufzubauen und den Restore Plan vorzubereiten. Dazu gehört unter anderem:
  • Welche Dateien sind wichtig?
  • Wem gehören die Dateien?
Fehlendes Wissen auf diesen Fragen kann meist mit Zeit und passenden Backups hergestellt werden.

3. Man stellt sich die Frage „Was genau muss nach dem teilweisen Restore besser sein oder wieder funktionieren?“ und schreibt diese Punkte in einen „Abnahmetest“. In diesem Fall z.B.:
  • Können sich die Teilnehmer wieder verbinden?
  • Funktioniert das Logging wie erwartet?
Aber auch das Thema Regression muss bedacht werden. Das könnte hier z.B. die Frage sein "Geht das Backup und Restore auch weiterhin nach der Umstellung?"

4. Beim teilweisen Restore geht man den vorher erstellen Restore Plan durch und folgt diesen Schritt für Schritt. Nach jedem Schritt überprüft man ob die gewünschten Änderung durchgeführt worden sind. Sollten weitere Änderungen notwendig sein, dann werden diese gleich nachdokumentiert. Am Ende startet man die CT und führt einen Abnahmetest durch. Sollte der Restore Plan nicht passend sein oder das Wissen nicht ausreichend, dann kann das ein paar Iterationen brauchen. Durch das im Schritt 1 erstellte Backup hat man einen guten Fallback falls diese Iterationen notwendig wären.

Aber hier kommen wir auch zu den Hinweisen/Warnungen:
  • Ich kenne den Code und die Stellen sehr gut und genau
  • Die CT ist nicht in irgendeiner Art und Weise kritisch
  • Die Backups sind in großer Anzahl vorhanden (nur leider nicht über den regulären PVE Weg restorbar)
  • Mein Wissen bezüglich Linux sowie Dateiberechtigungen ist mehr als ausreichend für den Restore Plan
Das heißt auch, dass mein teilweiser Restore Pfad nicht für alle der richtige sein wird ("Horses for courses"). Wenn z.B. diese CT missionskritisch und kaum Vorwissen vorhanden wäre, dann wäre dieser Ansatz möglichweise zu langsam oder fehleranfällig. Im selben Atemzug muss man aber auch sagen, dass für einen missionskritischen CT weder eine Überprüfung der Restorefähigkeit zu machen noch ein Fallback, falls diese nicht funktioniert, zu haben, schon sehr "risikofreudig" bzw. fahrlässig wäre.
 
Moin OF.
  • CTs sind grundsätzlich problematischer als VMs
  • Rohdaten überprüfe ich wegen bösen Buben auch per rsync auch auf auffällige Anderungen
  • das läuft dann aber komplett neben der Proxmox-Schiene
  • Ein Rohdaten-Restore will man nur als allerletzten Rettungsanker
  • Viel besser ist ein Restore einer virtuellen Maschine
  • Wenn man einem PBS nicht vollständig trauen will, dann eben mit x-Generationen per RAW-Sicherung
  • Ein PBS verifiziert jede Sicherung in definierbaren Zeiträumen
  • man kann jede Sicherung natürlich noch in Stein meißeln
Du hast aber rumgespielt ohne ein verlässliches Backup zu haben.
 
Gut, da ich das Fehlerverhalten auch nicht nachstellen kann, obwohl ich es jetzt schon auf verschiedenen Weisen versucht habe, mache ich das Backup nun händisch.
Naja, das finde ich keine gute Lösung, da die doch sehr umständlich und potentiell fehleranfällig ist. Hat es denn funktioniert OpenVPN in einen anderen Container zum laufen zu kriegen und diesen Container mit PBS zu sichern und wiederherzustellen? Falls ja, würde ich ja eher den alten VPN-Container wegwerfen und alles auf den neuen umziehen.
 
Naja, das finde ich keine gute Lösung, da die doch sehr umständlich und potentiell fehleranfällig ist. Hat es denn funktioniert OpenVPN in einen anderen Container zum laufen zu kriegen und diesen Container mit PBS zu sichern und wiederherzustellen? Falls ja, würde ich ja eher den alten VPN-Container wegwerfen und alles auf den neuen umziehen.

Ich glaube er meinte eher das Restore damit. Also so wie ich vorgeschlagen habe den Restore von Hand machen. Die Anleitung dafür hat er ja danach geschrieben.
 
Habe ich dich falsch verstanden oder die Frage falsch interpretiert?

Ich denke du hast meine Frage korrekt beantwortet, und mein Lösungsansatz hat im Nachgang nicht funktioniert. :)
Mit lxc-usernsexec werden die Berechtigungen im Container auf Berechtigungen außerhalb des Containers gemappt.
Fehlende Berechtigungen sind häufiger ein Problem, wenn Zugriffe an Berechtigungen scheitern. -
Ich bin vermutlich bei der Analyse des Strace an der falschen Stelle abgebogen/ man müsste mehr Zeit investieren/
tiefer in den Quellcode schauen (ein großer Vorteil von Open Source).

In dem Trace steht auch noch die Zeile [pid 17487] write(1, "Password for \"proxmox@pbs\": ", 28Password for "proxmox@pbs": ) = 28 und das dürfte der Schritt sein wo er auf den Backupstore zugreift. Ohne zeitintensive Quellcodeanalyse ist es halt ein wenig Trial and Error.
Da der ganze Thread hier leider etwas ausgedehnt ist, bin ich mir nicht mehr sicher, ob die Wiederherstellung eines weiteren blanken Containers gelungen war. GGf. ist die Herausforderung auch die allgemeine Berechtigungskonfiguration für Wiederherstellung vom Hypervisor aus.

Ich bin voll bei dir was das Backupthema angeht. Backups an sich braucht niemand ... nur nen funktionierenden Restore, wenn es wirklich darauf ankommt. :)
Für Restoretests, wäre es ggf. eine Lösung sich an den Readinessprobes von K8s zu orientieren - ein curl oder telnet um zu prüfen, ob sich ein port öffnet ist meistens schon sehr wertvoll.

BG, Lucas

PS: Freut mich das du deine Daten wiederherstellen konntest.
 
Ich glaube er meinte eher das Restore damit. Also so wie ich vorgeschlagen habe den Restore von Hand machen. Die Anleitung dafür hat er ja danach geschrieben.
Aber das kann doch nicht die Dauerlösung sein. Um das existierende Backup zu restoren ok, auf Dauer wäre mir das zu blöd
 
Hallo zusammen,

ich beantworte die Fragen / Punkte mal chronologisch:

* das läuft dann aber komplett neben der Proxmox-Schiene
Das ist korrekt. Die Ansätze es auf der "Proxmox-Schiene" zu machen sind in den vorigen Post dokumentiert. Proxmox hat mir aber keine andere Wahl gelassen als es händisch zu fixen.

* Ein Rohdaten-Restore will man nur als allerletzten Rettungsanker
Sehe ich grundsätzlich ähnlich, aber der "Proxmox-Schiene" Ansatz hat leider nicht funktioniert.

* Viel besser ist ein Restore einer virtuellen Maschine
Diese Aussage ist glaube entweder etwas verkürzt oder persönlich gefärbt. Wenn ich einen Restore mache und dieser 100% funktioniert wo ist der Unterschied ob das nun eine CT oder eine VM war? Was macht den Restore besser weil er für eine VM durchgeführt worden ist als für eine CT?

* Wenn man einem PBS nicht vollständig trauen will, dann eben mit x-Generationen per RAW-Sicherung
Bis zum Zeitpunkt der nicht Restorbarkeit des CT 110 hatte ich vollständiges Vertrauen in PBS.

* Ein PBS verifiziert jede Sicherung in definierbaren Zeiträumen
Alle Sicherungen der alten CT sind und waren verifiziert. Trotzdem konnten diese nicht durch PVE restored werden. Verifizierung ist also auch kein 100% zuverlässiger Indikator für die Restorbarkeit eines Backups in PVE oder PBS Zusammenspiel.

* Hat es denn funktioniert OpenVPN in einen anderen Container zum laufen zu kriegen und diesen Container mit PBS zu sichern und wiederherzustellen?
Diese Frage ist auch ein bisschen mehrdeutig für mich, daher beschreibe ich meine Sicht. Ich habe einen neuen Container aufgemacht, dort PiVPN (und somit OpenVPN) aufgespielt und Backup und Restore Test gemacht. Das war erfolgreich, aber ohne die passenden OpenVPN Dateien ist diese CT nutzlos, da man sich nicht dahin verbinden kann. Es braucht somit die „alten“ Daten von dem „alten“ CT. Daher habe ich schrittweise das Backup des „alten“ CT überspielt und wieder den Backup und Restore Prozess für den neuen CT geprüft. Am Ende habe ich jetzt einen „neuen“ CT mit den alten Daten. Diesen händischen Ablauf habe ich dokumentiert, da ich der Meinung bin, dass ein Forumpost ein gutes Mittel für zukünftige Hilfe zur Selbsthilfe sein kann.

* Aber das kann doch nicht die Dauerlösung sein. Um das existierende Backup zu restoren ok, auf Dauer wäre mir das zu blöd
Bin ich auch der Meinung, daher habe ich ein einmaligen Restore auf einen „neuen“ CT gemacht. Seitdem funktioniert auch der Backup & Restore von Proxmox wie man sich es erwarten würde. In meinen Post habe ich weder gesagt noch angedeutet, dass mein Ziel ist, diese „händische“ Variante regelmäßig zu leben.

Nun zu meinen letzter Punkt:
Terxleben, es ist bekannt, dass in Schriftform und Forumpost Teile einer Aussage verloren gehen können, da weder Stimmlage noch Körperhaltung vermittelt werden. Ich habe den Eindruck, dass in deinen Antworten oft eine gewisse Schärfe mitschwingt.
Besser so Herr Oberlehrer?
Du rufst aber eher mit "ich will, ich will" nach Mami.
Zusätzlich lieferst du unterirdische und willenlose "Informationen", die keine Sau reliabel beantworten kann.
Vielleicht hat irgendwer noch den Nerv, dir aus dem Bettchen zu helfen.
Das Ganze offenbar noch auf deinem persönlichen Spielplatz.
Du hast aber rumgespielt ohne ein verlässliches Backup zu haben.
Es wirkt ein bisschen so, als wärst du genervt oder frustriert von dem Thread. Ich denke, unsere Punkte bezüglich des Originalpost sind ausgetauscht.

Ich danke auch allen für eure Hilfe und ich wünsche euch noch einen schönen Tag!
 
  • Like
Reactions: bl1mp
Genervt war ich keine Sekunde. In einen schärferen Ton wechsele ich nur, wenn man mir unterstellt hier irgendwelche KI-Ergüsse einzustellen und dann anschließend sogar Haare spaltet. Das war nie in deine Richtung gerichtet.
Vielleicht wirke ich manchmal ruppig, bin aber selbst auch nicht zimperlich.
Es freut mich, dass du Meinungen unterschiedlicher Menschen zur Kenntnis nehmen konntest um einen für dich akzeptablen Weg zu wählen und sogar einer Zusammenfassung deiner Eindrücke zu schildern.
 
Last edited: