Kann Backup nicht einspielen

Lockslay

Active Member
Nov 27, 2020
134
1
38
51
Hallo zusammen,

ich habe aktuelle zwei Proxmox Server und einen PBS am laufen.
Da der erste Proxmoxserver probleme macht habe ich einen zweiten aufgesetzt und wollte die Bakups vom PBS einspielen.

Bei zwei Backups macht das Einpielen Probleme. Ich bekomme immer diese Meldung:

Code:
Header
Proxmox
Virtual Environment 8.3.2
Storage 'Proxmoxbs' auf Knoten 'debianproxmox'
Suche:
Logs
()
Formatting '/var/lib/vz/images/104/vm-104-disk-0.raw', fmt=raw size=34359738368 preallocation=off
new volume ID is 'local:104/vm-104-disk-0.raw'
restore proxmox backup image: /usr/bin/pbs-restore --repository root@pam@192.168.0.91:Backups vm/105/2025-01-06T23:15:58Z drive-scsi0.img.fidx /var/lib/vz/images/104/vm-104-disk-0.raw --verbose --format raw --skip-zero
connecting to repository 'root@pam@192.168.0.91:Backups'
open block backend for target '/var/lib/vz/images/104/vm-104-disk-0.raw'
starting to restore snapshot 'vm/105/2025-01-06T23:15:58Z'
download and verify backup index
progress 1% (read 343932928 bytes, zeroes = 8% (29360128 bytes), duration 3 sec)
progress 2% (read 687865856 bytes, zeroes = 4% (29360128 bytes), duration 6 sec)
progress 3% (read 1031798784 bytes, zeroes = 2% (29360128 bytes), duration 10 sec)
progress 4% (read 1375731712 bytes, zeroes = 2% (29360128 bytes), duration 15 sec)
progress 5% (read 1719664640 bytes, zeroes = 1% (29360128 bytes), duration 18 sec)
progress 6% (read 2063597568 bytes, zeroes = 1% (29360128 bytes), duration 23 sec)
progress 7% (read 2407530496 bytes, zeroes = 1% (29360128 bytes), duration 26 sec)
progress 8% (read 2751463424 bytes, zeroes = 1% (29360128 bytes), duration 32 sec)
progress 9% (read 3095396352 bytes, zeroes = 0% (29360128 bytes), duration 36 sec)
progress 10% (read 3439329280 bytes, zeroes = 0% (29360128 bytes), duration 42 sec)
progress 11% (read 3783262208 bytes, zeroes = 0% (37748736 bytes), duration 46 sec)
progress 12% (read 4127195136 bytes, zeroes = 0% (37748736 bytes), duration 51 sec)
progress 13% (read 4466933760 bytes, zeroes = 1% (54525952 bytes), duration 54 sec)
progress 14% (read 4810866688 bytes, zeroes = 1% (54525952 bytes), duration 60 sec)
progress 15% (read 5154799616 bytes, zeroes = 1% (54525952 bytes), duration 64 sec)
progress 16% (read 5498732544 bytes, zeroes = 0% (54525952 bytes), duration 69 sec)
progress 17% (read 5842665472 bytes, zeroes = 0% (54525952 bytes), duration 75 sec)
progress 18% (read 6186598400 bytes, zeroes = 0% (54525952 bytes), duration 80 sec)
progress 19% (read 6530531328 bytes, zeroes = 1% (79691776 bytes), duration 86 sec)
progress 20% (read 6874464256 bytes, zeroes = 1% (79691776 bytes), duration 95 sec)
progress 21% (read 7218397184 bytes, zeroes = 1% (79691776 bytes), duration 106 sec)
progress 22% (read 7562330112 bytes, zeroes = 1% (79691776 bytes), duration 115 sec)
progress 23% (read 7906263040 bytes, zeroes = 1% (79691776 bytes), duration 121 sec)
progress 24% (read 8250195968 bytes, zeroes = 0% (79691776 bytes), duration 128 sec)
progress 25% (read 8589934592 bytes, zeroes = 0% (79691776 bytes), duration 134 sec)
progress 26% (read 8933867520 bytes, zeroes = 1% (92274688 bytes), duration 142 sec)
progress 27% (read 9277800448 bytes, zeroes = 0% (92274688 bytes), duration 151 sec)
progress 28% (read 9621733376 bytes, zeroes = 0% (92274688 bytes), duration 160 sec)
progress 29% (read 9965666304 bytes, zeroes = 0% (92274688 bytes), duration 168 sec)
progress 30% (read 10309599232 bytes, zeroes = 0% (92274688 bytes), duration 175 sec)
progress 31% (read 10653532160 bytes, zeroes = 0% (92274688 bytes), duration 182 sec)
progress 32% (read 10997465088 bytes, zeroes = 0% (92274688 bytes), duration 190 sec)
progress 33% (read 11341398016 bytes, zeroes = 0% (92274688 bytes), duration 199 sec)
progress 34% (read 11685330944 bytes, zeroes = 0% (92274688 bytes), duration 208 sec)
progress 35% (read 12029263872 bytes, zeroes = 0% (92274688 bytes), duration 216 sec)
progress 36% (read 12373196800 bytes, zeroes = 0% (92274688 bytes), duration 224 sec)
progress 37% (read 12717129728 bytes, zeroes = 0% (92274688 bytes), duration 231 sec)
progress 38% (read 13056868352 bytes, zeroes = 0% (109051904 bytes), duration 237 sec)
progress 39% (read 13400801280 bytes, zeroes = 0% (109051904 bytes), duration 246 sec)
progress 40% (read 13744734208 bytes, zeroes = 0% (109051904 bytes), duration 253 sec)
progress 41% (read 14088667136 bytes, zeroes = 0% (109051904 bytes), duration 261 sec)
progress 42% (read 14432600064 bytes, zeroes = 0% (109051904 bytes), duration 267 sec)
progress 43% (read 14776532992 bytes, zeroes = 0% (109051904 bytes), duration 276 sec)
progress 44% (read 15120465920 bytes, zeroes = 0% (130023424 bytes), duration 281 sec)
progress 45% (read 15464398848 bytes, zeroes = 0% (130023424 bytes), duration 287 sec)
progress 46% (read 15808331776 bytes, zeroes = 0% (130023424 bytes), duration 295 sec)
progress 47% (read 16152264704 bytes, zeroes = 0% (130023424 bytes), duration 306 sec)
progress 48% (read 16496197632 bytes, zeroes = 0% (130023424 bytes), duration 316 sec)
restore failed: connection reset
temporary volume 'local:104/vm-104-disk-0.raw' successfully removed
error before or during data restore, some or all disks were not completely restored. VM 104 state is NOT cleaned up.
TASK ERROR: command '/usr/bin/pbs-restore --repository root@pam@192.168.0.91:Backups vm/105/2025-01-06T23:15:58Z drive-scsi0.img.fidx /var/lib/vz/images/104/vm-104-disk-0.raw --verbose --format raw --skip-zero' failed: exit code 255

Ich habe auch schon die Netzwerkübertarung verinnert, was aber auch nichts gebracht hat. Kann es sein das beim neuen Server ein storage oder was anderes fehlt? Ich glaube die zwei Backups sind VMś und die anderen sind CT. Hat eventuell einer eine Hilfreiche Idee?
 
Hi,
bitte auch die Task- und System-Logs auf PBS-Seite kontrollieren und den System-Log auf Proxmox VE-Seite. Tritt der Fehler immer an der gleichen Stelle auf? Gleiche Zeit oder gleiche Byte-Offset/Prozent?
 
  • Like
Reactions: Lockslay
Hallo und danke für deine Antwort.

Auf dem PBS habe ich folgendes gefunden:

Bildschirmfoto 2025-01-08 um 19.36.03.png

In den Logs vom PBS habe ich das gefunden:

Code:
an 08 19:40:00 pbs proxmox-backup-proxy[697]: unable to start datastore prune job default-backup-cb1d0967-df8d-4c6 - no such datastore 'backup'
Jan 08 19:40:00 pbs proxmox-backup-proxy[697]: unable to start datastore verification job v-2aeeed9d-4787 - no such datastore 'backup'
Jan 08 19:41:00 pbs proxmox-backup-proxy[697]: unable to start datastore prune job default-backup-cb1d0967-df8d-4c6 - no such datastore 'backup'
Jan 08 19:41:00 pbs proxmox-backup-proxy[697]: unable to start datastore verification job v-2aeeed9d-4787 - no such datastore 'backup'

1736361912964.png

Ich konnte fast alle VM / CT wiederherstellen, bis auf zwei 114 und 105
Was ich nicht verstehe "no such datastore 'backup'" steht in den Logs ich habe aber Datastore Backups und auf dem neuen Server werden mir auch alle Backups angezeigt.


Beim neuen Proxmox Server habe ich das angezeigt bekommen:

Code:
recovering backed-up configuration from 'Proxmoxbs:backup/ct/114/2025-01-08T08:29:11Z'
Formatting '/var/lib/vz/images/104/vm-104-disk-0.raw', fmt=raw size=10737418240 preallocation=off
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: f221ffde-4675-46a4-86be-4c6eb3a1facd
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Formatting '/var/lib/vz/images/104/vm-104-disk-1.raw', fmt=raw size=268435456000 preallocation=off
Creating filesystem with 65536000 4k blocks and 16384000 inodes
Filesystem UUID: 435f2abd-a4e0-4e33-b829-4b30fe27e92a
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872
restoring 'Proxmoxbs:backup/ct/114/2025-01-08T08:29:11Z' now..
HTTP/2.0 connection failed
Error: error extracting archive - encountered unexpected error during extraction: error at entry "192-256.jpg": failed to extract file: failed to copy file contents: connection reset
TASK ERROR: unable to restore CT 104 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/114/2025-01-08T08:29:11Z root.pxar /var/lib/lxc/104/rootfs --allow-existing-dirs --repository root@pam@192.168.0.91:Backups' failed: exit code 255

Würde mich sehr freuen, wenn einer hier Hilfstellung geben könnte.
VG
 
Das datastore hieß auf dem alten Server "Backups" und auf dem neuen "backup", ähnlich, aber eben nicht gleich bei Befehlspfadangabe.
 
Hallo und danke für den Hinweis, was ich aber nichzt nachvollziehen kann. Es ist doch egal wo jetzt das Backup liegt es wird doch vom PBS angezeigt.
Muss ich jetzt auf dem neuen PVE einen Datastore anlegen oder auf dem PBS Server ?
Ich dacjte immer es ist egal wo die Backups liegen solange diese wieder angezeigt werden. VG
 
Da der erste Proxmoxserver probleme macht habe ich einen zweiten aufgesetzt und wollte die Bakups vom PBS einspielen.
Es scheinen hier mehrere Probleme vorhanden zu sein. Wie wurde denn der 2-te Proxmox Backup Server aufgesetzt? Ist das eine komplette neuinstallation? Wurden configs vom bestehenden übernommen? Die issues mit dem nicht vorhandenen datastore der prune und verify jobs sollten aber nicht direkt mit dem restore fehler zusammenhängen. Bitte check mal die configs unter /etc/proxmox-backup/prune.cfg und /etc/proxmox-backup/verification.cfg die müssen den richtigen store konfiguriert haben.

Bezüglich restore:
HTTP/2.0 connection failed
restore failed: connection reset
Das schaut eher nach einem Netzwerkproblem aus. Kann es sein, dass hier vielleicht IPs doppelt vergeben wurden? Was liefert ein ip neigh am PVE, was am PBS? Ist ein ping vom PVE zum PBS kontinuierlich möglich?
 
Hallo,

danke für deinen Hinweis.
Hier sehen ich schon die ersten Unterschiede:


Code:
cat /etc/proxmox-backup/prune.cfg
prune: default-backup-cb1d0967-df8d-4c6
        keep-last 5
        schedule daily
        store backup

prune: default-backuptest-18211ea2-3de5
        schedule daily
        store backuptest

prune: default-Backups-0b76962b-1dda-46
        keep-last 5
        schedule daily
        store Backups
root@pbs:~# cat /etc/proxmox-backup/verification.cfg
verification: v-2aeeed9d-4787
        ignore-verified true
        ns
        outdated-after 30
        schedule daily
        store backup

Ist es eventuell Sinvoll diese beiden Einträge auszukommentieren:

prune: default-backuptest-18211ea2-3de5
schedule daily
store backuptest

prune: default-Backups-0b76962b-1dda-46
keep-last 5
schedule daily
store Backups


?

Auf dem neuen PVE sehe ich keine doppelten IP´s
Wie schon geschrieben, bis auf zei VM´S konnte ich alle Backups wieder herstellen was gegen ein Netzwerkproblem spricht.


Code:
ip neigh ip neigh
192.168.0.130 dev vmbr0 INCOMPLETE
192.168.0.202 dev vmbr0 lladdr dc:15:c8:13:bf:68 STALE
192.168.0.114 dev vmbr0 lladdr f0:2f:4b:08:63:f6 REACHABLE
192.168.0.23 dev vmbr0 lladdr 54:84:7b:00:30:2c STALE
192.168.0.177 dev vmbr0 lladdr 74:58:f3:34:38:41 STALE
192.168.0.95 dev vmbr0 lladdr 00:08:c9:44:0c:80 REACHABLE
192.168.0.149 dev vmbr0 lladdr 54:53:ed:db:49:f1 REACHABLE
192.168.0.96 dev vmbr0 lladdr 76:c0:90:56:fa:77 STALE
192.168.0.91 dev vmbr0 lladdr bc:24:11:20:48:c3 REACHABLE
192.168.0.24 dev vmbr0 lladdr 00:17:88:b0:1c:c6 STALE
192.168.0.1 dev vmbr0 lladdr dc:15:c8:13:bf:68 STALE
192.168.0.132 dev vmbr0 lladdr 24:5e:be:66:e2:c6 STALE
192.168.0.40 dev vmbr0 lladdr 56:a8:02:62:0c:f3 STALE
192.168.0.22 dev vmbr0 lladdr 6c:56:97:36:59:cf STALE
192.168.0.122 dev vmbr0 lladdr 54:8d:5a:a6:65:99 STALE
fe80::4a78:5eff:fe7b:81e2 dev vmbr0 lladdr 48:78:5e:7b:81:e2 STALE
fe80::1c53:9320:3d4c:95c dev vmbr0 lladdr 52:cb:51:36:22:f4 STALE
fe80::48b:ad3d:aa5d:bdfa dev vmbr0 lladdr 9a:d9:22:53:64:42 STALE
fe80::14db:a2a2:de5d:99c dev vmbr0 lladdr 26:0c:58:8f:86:50 STALE
fe80::10e2:14ff:fef6:af97 dev vmbr0 lladdr 12:e2:14:f6:af:97 STALE
fe80::1ab4:30ff:feac:e98d dev vmbr0 lladdr 18:b4:30:ac:e9:8d STALE
fe80::4a78:5eff:fee8:f902 dev vmbr0 lladdr 48:78:5e:e8:f9:02 STALE
fe80::406:cf7d:37aa:2512 dev vmbr0 lladdr 9a:d9:22:53:64:42 STALE
fe80::cfb:bfb1:b12a:d92d dev vmbr0 lladdr 96:d5:8b:5e:f9:87 STALE
fe80::cea7:c1ff:fe5c:28ae dev vmbr0 lladdr cc:a7:c1:5c:28:ae STALE
fe80::6616:66ff:fecf:499d dev vmbr0 lladdr 64:16:66:cf:49:9d STALE
fe80::1cc4:489e:1dfe:29ef dev vmbr0 lladdr 9a:d9:22:53:64:42 STALE
fe80::10ea:3f60:3942:a424 dev vmbr0 lladdr f0:2f:4b:08:63:f6 STALE
fe80::cea7:c1ff:fe5c:1f06 dev vmbr0 lladdr cc:a7:c1:5c:1f:06 STALE
fe80::78b8:8b60:b030:83e2 dev vmbr0 lladdr 74:a7:ea:b4:dc:6e STALE
fe80::e8c6:10ff:feec:cb8b dev vmbr0 lladdr ea:c6:10:ec:cb:8b STALE
fe80::c82a:45ff:fe41:734e dev vmbr0 lladdr ca:2a:45:41:73:4e STALE
fe80::be24:11ff:fe2c:280a dev vmbr0 lladdr bc:24:11:2c:28:0a STALE
fe80::303a:fdff:fe12:49b2 dev vmbr0 lladdr 32:3a:fd:12:49:b2 STALE
fe80::b6e4:54ff:feb3:bac6 dev vmbr0 lladdr b4:e4:54:b3:ba:c6 STALE
fe80::217:88ff:feb0:1cc6 dev vmbr0 lladdr 00:17:88:b0:1c:c6 STALE
fe80::cea7:c1ff:fe5c:207d dev vmbr0 lladdr cc:a7:c1:5c:20:7d STALE
fe80::187f:401e:91fb:5675 dev vmbr0 lladdr e2:02:85:97:e2:2e STALE
fe80::2778:9e87:27e2:59a5 dev vmbr0 lladdr 10:09:f9:16:0a:ac STALE
fe80::7842:7fff:fe64:3a54 dev vmbr0 lladdr 7a:42:7f:64:3a:54 STALE
fe80::6616:66ff:fecf:3e62 dev vmbr0 lladdr 64:16:66:cf:3e:62 STALE
fe80::d0ce:1eff:fe10:eeb6 dev vmbr0 lladdr d2:ce:1e:10:ee:b6 STALE
fe80::9c9b:cbff:fee8:2f8c dev vmbr0 lladdr 9e:9b:cb:e8:2f:8c STALE
fe80::1ab4:30ff:fe9d:d1bb dev vmbr0 lladdr 18:b4:30:9d:d1:bb STALE
fe80::108c:c746:fafa:28e8 dev vmbr0 lladdr 96:d5:8b:5e:f9:87 STALE
fe80::c66:2d6f:bea6:b874 dev vmbr0 lladdr ca:0f:61:47:78:28 STALE
fe80::54a8:2ff:fe62:cf3 dev vmbr0 lladdr 56:a8:02:62:0c:f3 STALE
fe80::14b3:2c77:d4ef:f921 dev vmbr0 lladdr fa:af:9e:a9:d4:3f STALE
fe80::be24:11ff:fe59:4561 dev vmbr0 lladdr bc:24:11:59:45:61 STALE
fe80::6616:66ff:fecf:50ee dev vmbr0 lladdr 64:16:66:cf:50:ee STALE
fe80::7084:93ff:fedb:ec86 dev vmbr0 lladdr 72:84:93:db:ec:86 STALE
fe80::1ab4:30ff:fe8a:81e4 dev vmbr0 lladdr 18:b4:30:8a:81:e4 STALE
fe80::1ab4:30ff:fe9e:3a94 dev vmbr0 lladdr 18:b4:30:9e:3a:94 STALE
fe80::be24:11ff:fe98:2d99 dev vmbr0 lladdr bc:24:11:98:2d:99 STALE
fe80::1c45:4548:2138:a880 dev vmbr0 lladdr 96:d5:8b:5e:f9:87 STALE
fe80::74c0:90ff:fe56:fa77 dev vmbr0 lladdr 76:c0:90:56:fa:77 STALE
fe80::ba27:ebff:fee5:feaa dev vmbr0 lladdr b8:27:eb:e5:fe:aa STALE
fe80::cea7:c1ff:fe5c:e90 dev vmbr0 lladdr cc:a7:c1:5c:0e:90 STALE
fe80::963a:91ff:feee:4aa dev vmbr0 lladdr 94:3a:91:ee:04:aa STALE
fe80::be24:11ff:fe18:5086 dev vmbr0 lladdr bc:24:11:18:50:86 STALE
fe80::6e56:97ff:fe36:59cf dev vmbr0 lladdr 6c:56:97:36:59:cf STALE
fe80::be24:11ff:fe54:2ae6 dev vmbr0 lladdr bc:24:11:54:2a:e6 STALE
fe80::be24:11ff:fe20:48c3 dev vmbr0 lladdr bc:24:11:20:48:c3 STALE
fe80::34aa:3eff:fed6:6ec9 dev vmbr0 lladdr 36:aa:3e:d6:6e:c9 STALE
 
st es eventuell Sinvoll diese beiden Einträge auszukommentieren:

prune: default-backuptest-18211ea2-3de5
schedule daily
store backuptest

prune: default-Backups-0b76962b-1dda-46
keep-last 5
schedule daily
store Backups
Nein, letzteres ist ja der prunejob für den existiereneden datastore Backups, der wird ja für den restore verwendet. Ich vermute mal das prune für diesen datastore ist gewünscht. Bei den anderen kann man nur raten, gibt es die datastores dazu? Wie sieht die cat /etc/proxmox-backup/datastore.cfg aus?

192.168.0.91 dev vmbr0 lladdr bc:24:11:20:48:c3 REACHABLE
Ok, zumindest zu diesem Zeitpunkt scheint der PBS erreichbar. Wie schauts mit dem ping während dem restore aus?

In den Logs vom PBS habe ich das gefunden:

an 08 19:40:00 pbs proxmox-backup-proxy[697]: unable to start datastore prune job default-backup-cb1d0967-df8d-4c6 - no such datastore 'backup' Jan 08 19:40:00 pbs proxmox-backup-proxy[697]: unable to start datastore verification job v-2aeeed9d-4787 - no such datastore 'backup' Jan 08 19:41:00 pbs proxmox-backup-proxy[697]: unable to start datastore prune job default-backup-cb1d0967-df8d-4c6 - no such datastore 'backup' Jan 08 19:41:00 pbs proxmox-backup-proxy[697]: unable to start datastore verification job v-2aeeed9d-4787 - no such datastore 'backup'
Poste bitte das gesamte systemd journal run um den Fehler während des restore... Mit folgendem Befehl (mit entsprechend angepassten Zeiten) journalctl --since <DATETIME> --until <DATETIME> > journal.txt kannst du das journal dumpen.

Weiters: Auf was für einem Storage befindet sich denn der datastore Backups von dem wiederhergestellt wird? Wie sieht das Netzwerk zwischen PBS und PVE aus? Eventuell die dazwischenliegende HW auf mögliche Netzwerkprobleme checken.
 
Hallo und vielen Danke für die zahlreichen Hilfestellungen.

Leider bekommen ich diese zwei Backups immer noch nicht eingespielt.
Wie schon geschrieben hat, dass einspielen von zahlreichen anderen VM und CT problemlos geklappt.
Was aus meiner Siucht gegen eine Netzwerkproblem spricht.


Ich habe auf meinem alt PVE eine VM mit dem PBS installiert.
Auf dem PBS werden die Backups auf meine NAS (Qnap)m mittells NFS gespeichert.

Ich. habe jetzt auch ein Storage auf dem PBS angelegt was die Daten lokal auf dem PBS speichert und nicht auf dem NAS.
Auch da bekomme ich die Abbrüche.

Was ich halt nicht verstehe, bei zwei Backups gibt es Probleme und alle anderen liefen einfach durch.
Ich habe jetzt noch überlegt einen exterene PBS auf einen Intel Nuc zu installieren und dann die Backups dort speicher und dann versiche ich diese einzuspielen. Ich wollte aber eingentlich so wenig wie möglich mit neuer Hardware arbeiten. Kann man die Backups eventeull mittels scp oder ssh vom PBS zu neuen PVE kopieren ?

journalctl --since "2025-01-01 00:00:00" --until "2025-01-13 23:59:59" > journal.txt



Jan 13 17:25:33 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:34 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:42 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:43 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:44 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:46 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:47 debianproxmox pvestatd[1206]: status update time (5.121 seconds)
Jan 13 17:25:53 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:54 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:55 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:57 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:57 debianproxmox pvestatd[1206]: status update time (5.147 seconds)
Jan 13 17:26:02 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:03 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:04 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:05 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:12 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:13 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:14 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:16 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:22 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:23 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:24 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)



Das verwundert mich jetzt extremst da die IP 192.168.0.130:8086 bei mir nicht hinterlegt ist und da auch keine PVE oder PBS laufen
 
Last edited:
Ich habe auf meinem alt PVE eine VM mit dem PBS installiert.
Auf dem PBS werden die Backups auf meine NAS (Qnap)m mittells NFS gespeichert.

Ich. habe jetzt auch ein Storage auf dem PBS angelegt was die Daten lokal auf dem PBS speichert und nicht auf dem NAS.
Auch da bekomme ich die Abbrüche.
Also es werden die Backups vom alten PVE auf die darauf laufende PBS VM gemacht und dann ein restore von der PBS VM auf den neuen PVE host versucht? Verstehe ich das richtig?

Kann man die Backups eventeull mittels scp oder ssh vom PBS zu neuen PVE kopieren ?
Nein, das geht nur via restore von einer PBS Instanz. Was aber gehen würde, ist entweder eine neue PBS Instanz (wiederum eine VM) und dann mittels Sync Job die snapshots auf die neuen PBS Instanz zu synchronisieren.

Aber ich würde zunächst mal versuchen einen restore direkt innerhalb den PBS instanz zu versuchen, da ist dann kein Netzwerk dazwischen.

journalctl --since "2025-01-01 00:00:00" --until "2025-01-13 23:59:59" > journal.txt



Jan 13 17:25:33 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:34 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:42 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:43 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:44 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:46 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:47 debianproxmox pvestatd[1206]: status update time (5.121 seconds)
Jan 13 17:25:53 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:54 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:55 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:57 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:25:57 debianproxmox pvestatd[1206]: status update time (5.147 seconds)
Jan 13 17:26:02 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:03 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:04 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:05 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:12 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:13 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:14 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:16 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:22 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:23 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Jan 13 17:26:24 debianproxmox pvestatd[1206]: metrics send error 'Proxmox': 500 Can't connect to 192.168.0.130:8086 (Connection timed out)
Ich hatte da das systemd journal der PBS instanz gemeint. Bitte deren gesamten Inhalt im entsprechenden Zeitraum posten.

Hinsichtlich dieses Fehlers: Vermutlich wurde hier ein externer influxdb metrik server eingerichtet der nicht mehr erreichbar ist?
 
Hallo, sorry ich hatte heute wenig Zeit.

Ich habe einen PVE auf diesem ist als VM der PBS eingerichtet.
Der PBS hat als Storage ein NFS Share auf meinem NAS, dort werden die Backups auf mehrern Platten gespeichert.

Ich habe jetzt auf neuer Hardware ein neue PVE installiert und vom PBS wollte ich die Backups einspielen.
Was bis auf zwei VM´s geklappt hat. Leider ist mindestens eine VM extremst wichtig für mich.

Ich habe brereits beim PBS ein Storage auf der Lokalen Platte eingerichtet und dort die Backups der fehlenden zwei VM´s abgelegt.
Leider klappte das auch nicht.

journalctl --since "15 minutes ago" --until "now" > journal.txt

cat journal.txt unter

https://pastebin.com/fukHFLAn

Bei 27% war leider Ende.
 
Im Journal bemängelt das System, dass es den Datastore "backup" nicht finden kann. In einem Screenshot vorher heißt dein Datastore aber "Backups". Könnte es daran liegen?
 
Okay, also laut PBS journal (ich gehe davon aus, dass dies den Zeitraum des restore beinhaltet?) keine Fehler welche dem restore zuzuordnen sind.

Wurde bereits geprüft ob während des restore das Netzwerk durchgehend in Ordnung ist? z.B. mittels kontinuierlichem ping wie vorgeschlagen?

Wurde der entsprechende backup snapshot am PBS verifiziert?

Ich habe jetzt auf neuer Hardware ein neue PVE installiert und vom PBS wollte ich die Backups einspielen.
Was bis auf zwei VM´s geklappt hat. Leider ist mindestens eine VM extremst wichtig für mich.

Wenn die VM und der CT noch am alten PVE zur Verfügung stehen, wäre es vermutlich einfacher ein reguläres Backup ohne PBS auf einen removable storage zu schreiben, und dieses dann am neuen PVE zu importieren. Das kann auch über ein NFS share erfolgen (dazu das NFS share bei beiden PVE hosts einrichten).

Es scheint mir als wären am alten PVE und PBS einige Misskonfigurationen zu beheben.
 
  • Like
Reactions: Johannes S
Hallo zusammen,


ich muss mich leider wieder melden da ich es immer noch nicht hinbekommen habe die beiden Backups einzuspielen.

DerPBS war laut ping immer erreichbar. Der Ping wurde vom neuen PVE ausgefü+hrt und hat den PBS angepingt.
Was ich nicht wirklich nachvollziehen kann.

bis auf zwei Backups konnte ich alle weiteren Backups ohne Probleme einspielen. Das spricht aus meiner Sicht nicht an ein Netzwerkproblem sonder er an ein Problem mit den Backups.

Im Journal bemängelt das System, dass es den Datastore "backup" nicht finden kann. In einem Screenshot vorher heißt dein Datastore aber "Backups". Könnte es daran liegen?
Das fällt mir auch auf, habe aber keine Idee wie ich das Datasore von Backups auf beackup umstellen kann. Es werden die Backups auch angezeigt und sollten dann doch ohne probleme eingespielt werden, egal von welchen Datastore das kommt.

Okay, also laut PBS journal (ich gehe davon aus, dass dies den Zeitraum des restore beinhaltet?) keine Fehler welche dem restore zuzuordnen sind.

Wurde bereits geprüft ob während des restore das Netzwerk durchgehend in Ordnung ist? z.B. mittels kontinuierlichem ping wie vorgeschlagen?

Wurde der entsprechende backup snapshot am PBS verifiziert?



Wenn die VM und der CT noch am alten PVE zur Verfügung stehen, wäre es vermutlich einfacher ein reguläres Backup ohne PBS auf einen removable storage zu schreiben, und dieses dann am neuen PVE zu importieren. Das kann auch über ein NFS share erfolgen (dazu das NFS share bei beiden PVE hosts einrichten).

Es scheint mir als wären am alten PVE und PBS einige Misskonfigurationen zu beheben.
Ich habe leider keine Möglichkeit auf dem PVE gefunden ein NFS share auf dem PVE einzurichten, könntest du da einen Tipp geben?
 
Ich habe leider keine Möglichkeit auf dem PVE gefunden ein NFS share auf dem PVE einzurichten, könntest du da einen Tipp geben?
Das mit dem NFS war nur ein Hinweis, da viele User bereits einen NFS server als shared storage verwenden. Das Backup kann auch ohne weiteres auf die local storage geschrieben werden (falls ausreichend Platz vorhanden) und dann z.B. mittels USB Stick oder via ssh/scp vom alten auf den neuen host übertragen werden, um dort wiederum vom local storage zu restoren. Backups auf local ist bei einer Standard Installation unter /var/lib/vz/dump zu finden.
 
  • Like
Reactions: Lockslay
Hallo zusammen,

Das mit dem NFS war nur ein Hinweis, da viele User bereits einen NFS server als shared storage verwenden. Das Backup kann auch ohne weiteres auf die local storage geschrieben werden (falls ausreichend Platz vorhanden) und dann z.B. mittels USB Stick oder via ssh/scp vom alten auf den neuen host übertragen werden, um dort wiederum vom local storage zu restoren. Backups auf local ist bei einer Standard Installation unter /var/lib/vz/dump zu finden.
Danke für den Hinweis, dass hatte ich zuerst flasch verstanden.

Ich habe aber einen kleinen Erfolg.
Beim neuen PVE habe ich unter Storage - local - Inhalt -> Import mit ausgewählt und dann konnte ich ein Backup ohne Probleme einspielen.

Das zweite Image macht aber immer noch Probleme.

Code:
Error: error extracting archive - encountered unexpected error during extraction: error at entry "Fotoshooting_-11.jpg": failed to extract file: failed to copy file contents: connection reset
TASK ERROR: unable to restore CT 108 - command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- /usr/bin/proxmox-backup-client restore '--crypt-mode=none' ct/114/2025-01-16T23:33:24Z root.pxar /var/lib/lxc/108/rootfs --allow-existing-dirs --repository root@pam@192.168.0.91:Backups' failed: exit code 255

So wie ich das lese, gibt es ein Problem mit der Fotoshooting_-11.jpg
Wenn es keine andere Lösung gibt versuche ich es mit scp zu kopieren und werde dann aber wieder eine PBS auf eigener Hardware installieren.

Danke für die Hilfe!
 
Wenn es keine andere Lösung gibt versuche ich es mit scp zu kopieren und werde dann aber wieder eine PBS auf eigener Hardware installieren.

Danke für die Hilfe!
Habt ihr da vielleicht so ein Schlangenöl-Instrusion-Detection-System dazwischen/daneben oder sowas? Kann man das mal irgendwie bypassen? Sollte bei verschlüsselten Verbindungen ja eigentlich nichts sehen, aber wer weiß...
Ja genau, sonst holen (falls es groß ist, vielleicht lieber rsync --inplace --part) und lokales restore probieren.

Ich hatte mal, dass im Datenstrom (waren Debian Pakete über HTTP) zufällig irgendwelche Bytes drin waren, die die IDS getriggert haben, die dann beiden ein TCP RST eingedrückt hat. Das hatte ich nur gefunden, als ich da in gigabyteweisen TCP dumps festgestellt hatte, dass die MAC vom RST "falsch" war (wobei "gute" IDS auch "richtige" MAC senden können).
 
Hallo in die Runde,

ich muss mich nochmals melden. Das Problem ist jetzt gefunden, ich habe aber keine Ahnung wie ich es gelöst bekommen.

Auf dem neu installierten PVE habe ich z.b. die 101 eine VM mit dem Namen Cloud laufen und das Backup was auf dem PBS liegt ist auch die ct/101
Bei den anderen sieht es ganz anders aus.
Unter 102 wird der Webserver angezeigt, wenn ich aber unter Backups gehe steht dann zwar auch 102 aber die VM von meinem vpn
Wie kann ich das so richtig Einstellen das auch die 102 Webserver das Backup 102 eingespielt wird?

1738153120858.png
 
Hallo,
wenn mehrere PVE host und andere Instanzen backups auf den selben datastore machen, kommt es sehr einfach zu Namenskonflikten, ja. Deshalb wurden namespaces eingeführt. Siehe https://pbs.proxmox.com/docs/storage.html#backup-namespaces

Es empfiehlt sich zumindest ein namespace pro PVE host/cluster. Der entsprechende namespace kann dann bei der Storage Konfiguration beim PVE angegeben werden, es sind dann nur backups von/zu diesem namespace sichtbar.