In letzter Zeit immer wieder hängende Backups von ceph -> nfs

Discussion in 'Proxmox VE (Deutsch)' started by fips, Jun 6, 2018.

  1. fips

    fips Member

    Joined:
    May 5, 2014
    Messages:
    112
    Likes Received:
    3
    Hallo Leute,

    ich habe vor ein paar Wochen von 5.1 auf 5.2 aktualisiert und seitdem bleibt mir nun alle 1-2 Tage ein Backup "hängen".
    Das Procedere:
    In der Früh schau ich mir die Logs an und sehe "backup failed: multiple problems" dann verbinde ich mich mit dem Cluster und sehe das ein Backup Task nach wie vor läuft.
    Wenn ich mir der Task anschaue:
    Code:
    INFO: Starting Backup of VM 208 (lxc)
    INFO: status = running
    INFO: CT Name: www.example.com
    INFO: backup mode: snapshot
    INFO: ionice priority: 7
    INFO: create storage snapshot 'vzdump'
    /dev/rbd7
    INFO: creating archive '/mnt/pve/Backup/dump/vzdump-lxc-208-2018_06_05-23_19_27.tar.lzo'
    
    Dann klicke ich auf stop und erhalte folgenden Output:
    Code:
    INFO: remove vzdump snapshot
    rbd: sysfs write failed
    can't unmap rbd volume vm-208-disk-1: rbd: sysfs write failed
    ERROR: Backup of VM 208 failed - command 'set -o pipefail && tar cpf - --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' --one-file-system '--warning=no-file-ignored' '--directory=/mnt/pve/Backup/dump/vzdump-lxc-208-2018_06_05-23_19_27.tmp' ./etc/vzdump/pct.conf '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | lzop >/mnt/pve/Backup/dump/vzdump-lxc-208-2018_06_05-23_19_27.tar.dat' failed: interrupted by signal
    
    Anschließend ist zum einen der CT immer locked (die wird von mir händisch unlocked) und zum anderen wenn ich wieder ein Backup machen will:
    Code:
    INFO: starting new backup job: vzdump 208 --remove 0 --mode snapshot --compress lzo --node ceph7 --storage Backup
    INFO: Starting Backup of VM 208 (lxc)
    INFO: status = running
    INFO: CT Name: www.example.com
    INFO: found old vzdump snapshot (force removal)
    rbd: sysfs write failed
    can't unmap rbd volume vm-208-disk-1: rbd: sysfs write failed
    INFO: backup mode: snapshot
    INFO: ionice priority: 7
    INFO: create storage snapshot 'vzdump'
    snapshot create failed: starting cleanup
    no lock found trying to remove 'backup'  lock
    ERROR: Backup of VM 208 failed - rbd snapshot 'vm-208-disk-1' error: rbd: failed to create snapshot: (17) File exists
    INFO: Backup job finished with errors
    TASK ERROR: job errors
    
    Also entferne ich den Snapshot mittels:
    Code:
    rbd snap rm ceph/vm-208-disk-1@vzdump
    Und versuche das Backup nochmals durchzuführen aber leider:
    Code:
    INFO: starting new backup job: vzdump 208 --node ceph7 --mode snapshot --compress lzo --remove 0 --storage Backup
    INFO: Starting Backup of VM 208 (lxc)
    INFO: status = running
    INFO: CT Name: www.example.com
    INFO: backup mode: snapshot
    INFO: ionice priority: 7
    INFO: create storage snapshot 'vzdump'
    mount: /dev/rbd7 is already mounted or /mnt/vzsnap0 busy
    umount: /mnt/vzsnap0/: not mounted
    command 'umount -l -d /mnt/vzsnap0/' failed: exit code 32
    ERROR: Backup of VM 208 failed - command 'mount -o ro,noload /dev/rbd7 /mnt/vzsnap0//' failed: exit code 32
    INFO: Backup job finished with errors
    TASK ERROR: job errors
    
    Also prüfe ich noch wer das rbd gemapped hat mit:
    Code:
    rbd status ceph/vm-208-disk-1
    
    und erhalte:
    Code:
    Watchers:
        watcher=172.30.3.27:0/2318717155 client.39789856 cookie=18446462598732840961
        watcher=172.30.3.27:0/2318717155 client.39789856 cookie=18446462598732840986
    
    Das ist die Ceph IP des Nodes auf dem ich Backup machen wollte...

    Mein Workaround ist dann: CT migrieren und Node neustarten, dann klappt es wieder für 1-2 Tage...
    Ich hoffe das Problem ist euch irgendwie bekannt und ihr könnt mir helfen.

    Danke
     
  2. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    1,278
    Likes Received:
    110
    Beim Abbruch des Backups scheint das Device noch gemountet zu bleiben. Damit schlägt dann ein weiterer Versuch fehl.

    Deine Beschreibung ist von einem laufenden Backup, das manuell abgebrochen wird. Die Frage ist doch, warum schlagen ca. alle 1-2 Tage die Backups der Container fehl? Was ist den die Fehlermeldung die bei "backup failed: multiple problems" zu sehen ist?
     
  3. fips

    fips Member

    Joined:
    May 5, 2014
    Messages:
    112
    Likes Received:
    3
    Genau, nun das Backup wird in der Nacht um 23:15 gestartet und sollte pro CT eigentlich in 1-2 Minuten fertig sein.
    In dem von mir beschriebene Fall ist in der Früh der Backuptask immer noch nicht fertig, er hängt einfach. Ich sehe leider nicht genau woran es scheitert.
    Das einzige das in der Mail bei "backup failed: multiple problems ist
    Code:
    can't aquire lock '/var/run/vzdump.lock' - got timeout
     
  4. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    1,278
    Likes Received:
    110
    Im Task Log sollte ein ganzer Auszug des Backups vorhanden sein. Der Timeout passiert, weil ein Backup schon einen Lock hält. Sind es immer die selben Container die fehlschlagen? Wie schaut die vmid.conf der Container aus?
     
  5. fips

    fips Member

    Joined:
    May 5, 2014
    Messages:
    112
    Likes Received:
    3
    Leider nur das hier:
    Code:
    INFO: trying to get global lock - waiting...
    ERROR: can't aquire lock '/var/run/vzdump.lock' - got timeout
    TASK ERROR: got unexpected control message:  
    Ich habe das Gefühl das es häufiger beim CT 208 ist, aber ganz sicher auch schon bei anderen.
    Den 208er hab ich auch schon komplett gelöscht und aus dem Backup wiederhergestellt.
    208.conf:
    Code:
    arch: amd64
    cores: 2
    hostname: www.example.com
    memory: 2048
    nameserver: 10.0.10.3
    net0: name=eth0,bridge=vmbr1,gw=10.0.10.3,hwaddr=DE:EC:D9:98:A9:AB,ip=10.0.10.97/24,tag=10,type=veth
    ostype: debian
    rootfs: ceph_ct:vm-208-disk-1,size=20G
    searchdomain: example.it
    swap: 4096
    
     
  6. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    1,278
    Likes Received:
    110
    Laufen auf dem System mehrere Backup Jobs gleichzeitig? Wie schaut der Inhalt von /etc/pve/vzdump.cron aus?
     
  7. fips

    fips Member

    Joined:
    May 5, 2014
    Messages:
    112
    Likes Received:
    3
    Ja:
    Code:
    15 23 * * 1,2,3,4,5,7 root vzdump 101 105 111 113 115 201 202 204 205 207 208 209 210 215 216 401 211 611 212 213 219 218 217 104 103 206 221 220 102 116 --mailnotification always --quiet 1 --compress lzo --mailto admin@example.com --mode snapshot --storage Backup
    15 23 * * 1,2,3,4,5,7 root vzdump 108 110 601 602 603 604 605 114 609 608 610 107 116 100 --mailnotification always --mailto admin@example.com --mode snapshot --storage OffsiteBackup --compress lzo --quiet 1
    
    Ich kann auch schon deine Antwort Voraussagen: Teil die Backups auf mehrere Jobs auf ;-)
     
  8. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    1,278
    Likes Received:
    110
    Die Backup Jobs blockieren sich, der erste Job brauch länger als der zweite Job warten kann (timeout). Auf einer Node werden die Jobs immer seriell abgearbeitet. Ändere die Zeit des zweiten Jobs nach hinten, am besten wenn der erste Fertig ist.
     
  9. fips

    fips Member

    Joined:
    May 5, 2014
    Messages:
    112
    Likes Received:
    3
    Schade, ich wollte schon fast den Thread als "Solved" markieren und sagen alles in Ordnung, aber leider ist es heute wieder passiert.
    Diesmal mit einem anderen CT auf einem anderen Node als oben in den Logs aber mit exakt dem gleichen Fehlerbild.
    Die beiden Backupjobs im vzdump.cron wurden um 2 Stunden auseinander gesetzt.
    Der Zeitstempel im hängenden Backup zeigt eine Uhrzeit zu der kein anderes Backup oder etwas anderes großes (Wartung, große Filetransfer, sonstige Netzwerkauslastung) passiert ist.
     
  10. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    1,278
    Likes Received:
    110
    Es geht ja um die Dauer. Der erste Job holt sich das Lock und gibt es erst nach Abschluss wieder her. Ein zweiter Job wartet bis zu 3h auf die Freigabe, bekommt er die nicht dann bricht er ab. Dies gilt pro Node, sprich mehrere Jobs auf unterschiedlichen Nodes können gleichzeitig laufen.
     
  11. fips

    fips Member

    Joined:
    May 5, 2014
    Messages:
    112
    Likes Received:
    3
    ok gut, aber wie kann ich prüfen warum der erste Job hängt??
    Die einzelnen CT sollten ja in 1-2 Minuten gesichert sein, wenn er dann hängt läuft er in den Timeout.
     
  12. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    1,278
    Likes Received:
    110
    Ich denke, das Backup eines CT dauert schon länger als 1-2 Minuten. Das sollte auch im Log sichtbar sein. Ansonsten kann der Job auch auf der CLI von Hand ausgeführt werden (Zeile aus dem Cron). Dann heißt es, schauen was passiert, Server und Backup überwachen.
     
  13. fips

    fips Member

    Joined:
    May 5, 2014
    Messages:
    112
    Likes Received:
    3
    Das Backup des (heute hängenden) 209er CT hat vorgestern exact 00:00:59 gedauert, konnte das der "Backup Status" Mail entnehmen.
     
  14. Alwin

    Alwin Proxmox Staff Member
    Staff Member

    Joined:
    Aug 1, 2017
    Messages:
    1,278
    Likes Received:
    110
    Dann bleibt nur noch.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice