Probleme mit dem Restore

[Strizz]

Hallo,
ich habe den Umstieg von Proxmox 6.4 auf 7.2 genutzt, um mein System ganz neu aufzusetzen. Von jedem LXC und jeder VM waren 5 Versionen vorhanden, die laut Log-File alle OK waren, so dass ich vor dem Update eigentlich ganz zuversichtlich war. Leider war ich da zu optimistisch.
Bei zwei Containern habe ich folgendes Problem, dass der Restore-Prozess abgebrochen wird, weil nicht genügend Speicherplatz vorhanden sind.

recovering backed-up configuration from 'Syn_214play:backup/vzdump-lxc-108-2022_07_01-05_41_39.tar.lzo' Formatting '/mnt/pve/data/images/108/vm-108-disk-0.raw', fmt=raw size=107374182400 preallocation=off Creating filesystem with 26214400 4k blocks and 6553600 inodes Filesystem UUID: a9e72b9a-2031-4b26-a226-55e72cf9f368 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872 restoring 'Syn_214play:backup/vzdump-lxc-108-2022_07_01-05_41_39.tar.lzo' now.. extracting archive '/mnt/pve/Syn_214play/dump/vzdump-lxc-108-2022_07_01-05_41_39.tar.lzo' tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-00000000000cb488-0005c62a51f1f558.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@0005c779a9d3b7cc-f6677dce4857995b.journal~: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@ba8616390d5a4f01aee306e650499edd-0000000000000001-0005b4b1f6054e0b.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-00000000000e0c0b-0005c691c1dfe32a.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-000000000004adc1-0005c8e833754ec1.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-000000000010b457-0005cc8bad052bc3.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-000000000000ab44-0005c7b0715df758.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-00000000000804a0-0005c9eb2b17f461.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-00000000000a08a1-0005c5594ae4bc89.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-00000000000ab095-0005caba3587752c.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-000000000001563b-0005c7e4a760ebb8.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-000000000004b0c1-0005c3b73df8d710.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-000000000018b802-0005cef95a17d624.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-00000000001ebbfa-0005d0ca7082c39e.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-000000000020d176-0005dd2496c24a52.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-000000000008b2b0-0005c4f0ba7205cb.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-00000000001aba1d-0005cf939b02fdd6.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-0000000000055bca-0005c3eb5cc72759.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@0005b22b2cbef79d-f45f9a2b52ee3c36.journal~: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-00000000000b5e96-0005c5c1c1a5e0b1.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-0000000000035aca-0005c34eb303558f.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-00000000001a0f26-0005cf5fcd03ab91.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@d2e5f54dc6fa493b9f2959b2e4db5679-00000000001f6760-0005d0fddd09a00a.journal: Cannot write: No space left on device tar: ./var/log/journal/b354c482f7cc342776f020ee5ea440c3/system@753216c247814a3f9cc3294d727a2084-000000000000ae37-0005c27e15203b0e.journal: Cannot write: No space left on device .........

Was ist nun damit gemeint "No space left on device"? Plattenspeicher ist noch reichlich vorhanden. Kann ich beim Zurückspielen des Backups die Größe des anzulegenden Containers noch beeinflussen?

Vielleicht kann mit jemand auf die Sprünge helfen. Im Augenblick bin ich ratlos.


Strizz

 

[Pifouney]

hey,

can you give us the result of "df -h" ?

 

[Strizz]

HI,

the result of df-h is

root@proxmox:~# df -h Filesystem Size Used Avail Use% Mounted on udev 16G 0 16G 0% /dev tmpfs 3.2G 1.3M 3.2G 1% /run /dev/mapper/pve-root 94G 3.5G 86G 4% / tmpfs 16G 46M 16G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/nvme0n1p2 511M 328K 511M 1% /boot/efi /dev/sda1 916G 59G 811G 7% /mnt/pve/data /dev/fuse 128M 20K 128M 1% /etc/pve 192.168.20.10:/volume1/proxmox 3.6T 2.0T 1.6T 56% /mnt/pve/Syn_214play tmpfs 3.2G 0 3.2G 0% /run/user/0

Strizz

 

[fabian]

ja kannst du - zumindest auf der CLI - sh. "Advanced Restore Mode"

https://pve.proxmox.com/pve-docs/chapter-pct.html#_restoring_container_backups

 

[Strizz]

ja kannst du - zumindest auf der CLI - sh. "Advanced Restore Mode"

https://pve.proxmox.com/pve-docs/chapter-pct.html#_restoring_container_backups

Danke für den Hinweis. Mal sehen, ob ich da durchsteige.

Strizz

 

[Strizz]

Hi,
beim Restore eines anderen Containers ist jetzt noch ein zweite Problem aufgetaucht. Das Restore wird immer mit dem exit code 2 abgebrochen. Das Log sieht dann so aus:

recovering backed-up configuration from 'Syn_214play:backup/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo' Formatting '/mnt/pve/data/images/108/vm-108-disk-0.raw', fmt=raw size=322122547200 preallocation=off Creating filesystem with 78643200 4k blocks and 19660800 inodes Filesystem UUID: e11852bc-e819-48de-95b4-94fc62168849 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616 restoring 'Syn_214play:backup/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo' now.. extracting archive '/mnt/pve/Syn_214play/dump/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo' lzop: <stdin>: Compressed data violation tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now TASK ERROR: unable to restore CT 108 - command 'set -o pipefail && cstream -t 0 | lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf - --lzop --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/108/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2

Diese Fehlermeldung tritt bei allen 5 Sicherungsdateien auf. Das Backup wurde von Proxmox beim Erstellen jedoch immer als "OK" bezeichnet.
Frage: Ist da noch irgendwas zu retten? Was kann ich denn tun, damit so etwas nicht noch einmal passiert? Wenn Proxmox meldet: Backup OK, muss ich doch eigentlich davon ausgehen können, dass ich eine funktionierende Datensicherung besitze. Oder sehe ich das nicht richtig?

Strizz

 

[fabian]

was ist denn der backup storage? die fehlermeldung ist immer ident? klingt nach kaputtem storage oder memory..

 

[Strizz]

Die Daten werden auf meiner Synology (DS214play, Raid1, 2 neue 2T Seagate HD) gesichert. Wenn es an den Platten liegen sollte, warum dann 5 mal bei einer bestimmten LXC-Sicherung und bei allen anderen Backups nicht ? Ich verstehe es nicht.
Es handelt sich bei dieser Sicherung um einen Nextcloud-Server. Besteht irgendeine Chance, von den darauf gespeicherten Daten noch was zu retten?
Strizz

 

[fabian]

kann verschiedene gruende haben - z.b. mehr daten im backup -> groessere chance dass der fehler auftritt. ob es moeglich ist das korrupte archive teilweise oder ganz zu "retten" kann ich dir nicht sagen. was passiert denn wenn du

lzop -t -vv /mnt/pve/Syn_214play/dump/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo

ausfuehrst?

 

[Strizz]

@fabian: Da erhalte ich die Meldung
lzop: /mnt/pve/Syn_214play/dump/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo: Checksum error
FAILED

Strizz

 

[fabian]

folgendes ist eventuell noch einen versuch wert: lzop -d -F -v /mnt/pve/Syn_214play/dump/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo (-F bedeutet checksummen ignorieren). falls es klappt hast du ein wahrscheinlich wiederum korruptest tar archive - daraus lassen sich vielleicht noch dateien extrahieren..

ich wuerde auf jeden fall ein memtest auf der PVE kiste vorschlagen und die platten des NAS checken.

 

[Strizz]

@fabian: Leider auch hier dasselbe Ergebnis:

lzop -d -F -v /mnt/pve/Syn_214play/dump/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo
decompressing /mnt/pve/Syn_214play/dump/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo into /mnt/pve/Syn_214play/dump/vzdump-lxc-105-2022_07_01-04_13_15.tar
lzop: /mnt/pve/Syn_214play/dump/vzdump-lxc-105-2022_07_01-04_13_15.tar.lzo: Compressed data violation
FAILED

Speicher testen mache ich noch, aber hierbei hilft es ja nicht wirklich. Könnte allenfalls für die Zukunft relevant werden. Noch irgendeine Idee?

Strizz

 

[fabian]

der fehler scheint von hier zu kommen:
https://sources.debian.org/src/lzop/1.04-2/src/p_lzo.c/?hl=542#L542

ein lzop mit dem debug print aktiv wuerde uns zumindest sagen, ob die corruption ein laengen mismatch oder was anderes ist.

dd_rescue hat scheinbar ein lzo plugin, dass eventuell noch einen versuch wert ist - ich hab allerdings keine erfahrung damit: http://www.garloff.de/kurt/linux/ddrescue/ddr_lzo.html

 

[Strizz]

@fabian: Erst mal Danke für die Mühe. Aber da hört es für mich dann doch auf. Da muss ich meine Daten dann wohl abschreiben. Schade!
Diese Probleme mit dem Restore hinterlassen doch für die Zukunft ein sehr ungutes Gefühl bei mir. Von 8 LXC lassen sich 2 nicht wiederherstellen. 2 VMs, auf denen Docker läuft, funktionieren zwar wieder, erlauben jetzt aber keinen Zugriff mehr auf die Shell: Passwort wird nicht mehr erkannt.
Würde es helfen, wenn ich statt der Snapshots, einen Backup-Server aufsetzen würde?

Strizz

 

[Dunuin]

Als erstes mal würde ich memtest86+ über nacht auf dem PVE host laufen lassen und gucken ob es am Morgen dann keine RAM-Fehler gab. Die beste Backup-Software bringt nichts, wenn da die Daten schon beim Verarbeiten im RAM kaputt gehen. Deshalb wird ja auch zu ECC RAM geraten, dass das garnicht erst unbemerkt stattfinden kann.
Und dann wie gesagt mal einen langen SMART Selbsttest über die HDDs laufen lassen und gucken ob da alles OK ist.
Sollte mit den HDDs oder RAM etwas nicht stimmen, dann wäre es egal, wie du deine Backups/Snapshots erstellen würdest.

Wenn du die Hardware-Fehler ausgeschlossen hast, dann kann man weiter gucken.

 

[Strizz]

@Dunuin: Das werde ich mir sicherlich mal vornehmen, obwohl es mir ziemlich unwahrscheinlich vorkommt. Ein Speicherfehler hätte sich sicherlich auch auf andere Backups ausgewirkt und nicht nur immer auf ein und dasselbe Backup. Aber, um alles auszuschließen werde ich mir das mal vornehmen.
Trotzdem: Danke für den Hinweis
Strizz

 

[fabian]

wie gesagt, die ursache kann hier an vielen punkten zu suchen sein (memory PVE, memory synology, disken synology, falsch gesetzte cache settings, ..). bei PBS hast du die moeglichkeit komfortabel ein "verify" anzustossen um sicherzugehen dass ein backup snapshot nicht korrupt ist, bei "klassischen" backups erfordert dies ein restore (und die garantien dabei sind geringer als bei PBS, wo *immer* starke checksummen verwendet werden).