Backup von VM bricht immer ab error 125
- Thread starter Chucky
- Start date
Hmm, klingt jetzt für mich wie das es durch einen Benutzer abgebrochen wurde. Ein bisschen mehr Infos benötigen wir schon...
Und poste doch bitte das gesamte Log des Backups von dieser VM.
Danke.
Code:
pveversionDanke.
Code:
INFO: starting new backup job: vzdump 100 --storage server --remove 0 --compress zstd --mode snapshot --node pve
INFO: Starting Backup of VM 100 (qemu)
INFO: Backup started at 2020-10-06 02:42:27
INFO: status = running
INFO: VM Name: iobroker
INFO: include disk 'sata0' 'local-lvm:vm-100-disk-0' 32G
INFO: include disk 'sata1' 'local-lvm:vm-100-disk-1' 32G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: snapshots found (not included into backup)
INFO: creating vzdump archive '/mnt/pve/server/dump/vzdump-qemu-100-2020_10_06-02_42_27.vma.zst'
INFO: issuing guest-agent 'fs-freeze' command
INFO: issuing guest-agent 'fs-thaw' command
INFO: started backup task '1a3c5a3b-d3d8-4f19-813e-22eb9dad6ec3'
INFO: resuming VM again
INFO: 6% (4.3 GiB of 64.0 GiB) in 3s, read: 1.4 GiB/s, write: 0 B/s
INFO: 13% (8.4 GiB of 64.0 GiB) in 6s, read: 1.4 GiB/s, write: 0 B/s
INFO: 19% (12.4 GiB of 64.0 GiB) in 9s, read: 1.3 GiB/s, write: 0 B/s
INFO: 25% (16.6 GiB of 64.0 GiB) in 12s, read: 1.4 GiB/s, write: 0 B/s
INFO: 32% (20.7 GiB of 64.0 GiB) in 15s, read: 1.4 GiB/s, write: 0 B/s
INFO: 38% (24.8 GiB of 64.0 GiB) in 18s, read: 1.4 GiB/s, write: 0 B/s
INFO: 45% (28.9 GiB of 64.0 GiB) in 21s, read: 1.4 GiB/s, write: 0 B/s
INFO: 50% (32.1 GiB of 64.0 GiB) in 24s, read: 1.1 GiB/s, write: 8.6 MiB/s
INFO: 51% (32.7 GiB of 64.0 GiB) in 36s, read: 44.9 MiB/s, write: 41.0 MiB/s
INFO: 52% (33.3 GiB of 64.0 GiB) in 48s, read: 52.3 MiB/s, write: 49.4 MiB/s
INFO: 53% (33.9 GiB of 64.0 GiB) in 1m 3s, read: 44.5 MiB/s, write: 42.7 MiB/s
INFO: 54% (34.6 GiB of 64.0 GiB) in 1m 16s, read: 49.8 MiB/s, write: 41.0 MiB/s
INFO: 55% (35.2 GiB of 64.0 GiB) in 1m 30s, read: 49.7 MiB/s, write: 47.6 MiB/s
INFO: 56% (36.1 GiB of 64.0 GiB) in 1m 44s, read: 59.0 MiB/s, write: 43.1 MiB/s
INFO: 59% (38.1 GiB of 64.0 GiB) in 1m 47s, read: 713.9 MiB/s, write: 15.2 MiB/s
INFO: 60% (38.4 GiB of 64.0 GiB) in 1m 55s, read: 35.6 MiB/s, write: 35.6 MiB/s
INFO: 61% (39.0 GiB of 64.0 GiB) in 2m 12s, read: 37.6 MiB/s, write: 37.6 MiB/s
INFO: 62% (39.7 GiB of 64.0 GiB) in 2m 30s, read: 37.0 MiB/s, write: 36.9 MiB/s
INFO: 63% (40.3 GiB of 64.0 GiB) in 2m 44s, read: 45.7 MiB/s, write: 38.3 MiB/s
INFO: 64% (41.0 GiB of 64.0 GiB) in 2m 58s, read: 48.5 MiB/s, write: 46.7 MiB/s
INFO: 65% (41.6 GiB of 64.0 GiB) in 3m 13s, read: 44.3 MiB/s, write: 41.1 MiB/s
INFO: 66% (42.3 GiB of 64.0 GiB) in 3m 24s, read: 58.1 MiB/s, write: 42.2 MiB/s
INFO: 67% (42.9 GiB of 64.0 GiB) in 3m 40s, read: 41.7 MiB/s, write: 41.7 MiB/s
INFO: 68% (43.5 GiB of 64.0 GiB) in 3m 57s, read: 37.4 MiB/s, write: 37.4 MiB/s
INFO: 69% (44.2 GiB of 64.0 GiB) in 4m 11s, read: 46.8 MiB/s, write: 38.4 MiB/s
INFO: 70% (44.8 GiB of 64.0 GiB) in 4m 26s, read: 43.5 MiB/s, write: 43.5 MiB/s
INFO: 70% (45.4 GiB of 64.0 GiB) in 4m 42s, read: 40.1 MiB/s, write: 40.1 MiB/s
ERROR: job failed with err -125 - Operation canceled
INFO: aborting backup jobhmm, gut, aber wer macht den "aborting backup job"? Habs hier grad mal getestet. Die Meldung scheint direkt vom System zu kommen, da wird was abgebrochen. Wenn ein User abbricht schaut es so aus:
Was könntest du austesten um den Fehler zu finden, oder zumindest ein zu grenzen?
Code:
ERROR: interrupted by signal
INFO: aborting backup job
ERROR: Backup of VM 104 failed - interrupted by signal
INFO: Failed at 2020-10-06 16:10:27
ERROR: Backup job failed - interrupted by signal
TASK ERROR: interrupted by signalWas könntest du austesten um den Fehler zu finden, oder zumindest ein zu grenzen?
- Das Journallog/Syslog auf mögliche Hinweise zu dieser Zeit wo das Backup läuft/fehl schlägt zu durchsuchen
- Das Backup mal am Tag starten, oder eben zu einer ganz anderen Zeit
- Storagewechsel -> mal wo anders hin sichern
- Du hast ne sehr langsame Schreibgeschwindigkeit auf das Backupmedium, was ist denn das ganz genau, und über welches Protokoll kopierst du die Daten?
- Das Snapshot löschen und Sicherung nochmal testen.
- Warum verwendest du eingeschränkte SATA Controller und nicht SCSI?
Du fährst die VM runter, hängst die virtuellen Platten in der Hardwareconfig aus, und fügst sie neu hinzu als SCSI. Sofern die VM die virtuelle Hardware versteht funktioniert es sofort. Bei Ubuntu, CentOS, Debian, tut das so. Windows braucht hier extra Treiber.
Sofern die VM auf SSD liegt, ja.
Ja klar. Werden ja bei einem USBstick, wenn du ihn vom Rechner absteckst die Daten ja auch nicht gelöscht. Richtig?
Last edited:
Du kannst immer eine VM runterfahren, mit ssh auf den host gehen und dann dir eine Sicherung per cp machen um sicher zu gehen und hast so die Möglichkeit auf eine Kopie zuzugreifen.
Ich nehme an nach Plattenplatz hast Du bereits geschaut und auch mal alle Snapshots vor der Sicherung gelöscht? Ist eine Disk fast leer? Weil am Anfang wird gar nichts geschrieben und sehr schnell gelesen.
Ich nehme an nach Plattenplatz hast Du bereits geschaut und auch mal alle Snapshots vor der Sicherung gelöscht? Ist eine Disk fast leer? Weil am Anfang wird gar nichts geschrieben und sehr schnell gelesen.
Danke für eure Hilfe
ich habe es jetzt umgestellt , leider immer noch die selben Fehler . Ich habe schon meine FRITZ!Box in Verdacht , seit dem neusten Update .
Platz Probleme habe ich nicht. Lokal Backup geht auch nicht. Error 5
was ist eine Sicherung per cp?
ich habe es jetzt umgestellt , leider immer noch die selben Fehler . Ich habe schon meine FRITZ!Box in Verdacht , seit dem neusten Update .
Platz Probleme habe ich nicht. Lokal Backup geht auch nicht. Error 5
was ist eine Sicherung per cp?
Last edited:
Vergiss cp, das ist nur ein Notnagel, und da würde ich rsync nehmen. Versuch doch mal die Sicherung, sofern Platz lokal ab zu speichern, oder irgendwo anders hin. Damit wir mal nen anderen Vergleich haben. Und poste mal "wie schon oben geschrieben" dein Journal während einer Sicherung. Vielleicht sehen wir ja da schon den Error.