Backups failing, cant umount

AGo

New Member
Dec 9, 2010
12
0
1
Hi everybody,


I have a simple PVE 2 set up with 4 openvz to backup nightly.


The backup works fine for a number of days, then a backup process apparently for no reason does not finish, here is the log of the backup


Code:
INFO: starting new backup job: vzdump 101 104 106 108 --quiet 1 --mode snapshot  --compress gzip --storage backup
INFO: filesystem type on dumpdir is 'cifs' -using /var/tmp/vzdumptmp281434 for temporary files
INFO: Starting Backup of VM 101 (openvz)
INFO: CTID 101 exist mounted running
INFO: status = running
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating lvm snapshot of /dev/mapper/pve-data ('/dev/pve/vzsnap-root100-0')
INFO:   Logical volume "vzsnap-root100-0" created
INFO: creating archive '/backup/vms/dump/vzdump-openvz-101-2012_08_04-05_00_01.tar.gz'
INFO: Total bytes written: 623001600 (595MiB, 9.7MiB/s)
INFO: archive file size: 254MB
INFO: delete old backup '/backup/vms/dump/vzdump-openvz-101-2012_08_03-05_00_01.tar.gz'
INFO: Finished Backup of VM 101 (00:01:12)
INFO: Starting Backup of VM 104 (qemu)
INFO: status = running
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO:   Logical volume "vzsnap-root100-0" created
INFO: creating archive '/backup/vms/dump/vzdump-qemu-104-2012_08_04-05_01_13.tar.gz'
INFO: adding '/backup/vms/dump/vzdump-qemu-104-2012_08_04-05_01_13.tmp/qemu-server.conf' to archive ('qemu-server.conf')
INFO: adding '/mnt/vzsnap0/images/104/vm-104-disk-1.qcow2' to archive ('vm-disk-ide0.qcow2')
INFO: Total bytes written: 21172455936 (14.54 MiB/s)
INFO: archive file size: 13.93GB
INFO: delete old backup '/backup/vms/dump/vzdump-qemu-104-2012_08_03-05_01_04.tar.gz'
INFO: Finished Backup of VM 104 (00:23:13)
INFO: filesystem type on dumpdir is 'cifs' -using /var/tmp/vzdumptmp281434 for temporary files
INFO: Starting Backup of VM 106 (openvz)
INFO: CTID 106 exist mounted running
INFO: status = running
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating lvm snapshot of /dev/mapper/pve-data ('/dev/pve/vzsnap-root100-0')
INFO:   Logical volume "vzsnap-root100-0" created
INFO: creating archive '/backup/vms/dump/vzdump-openvz-106-2012_08_04-05_24_27.tar.gz'
INFO: Total bytes written: 25170360320 (24GiB, 9.8MiB/s)
INFO: umount: /mnt/vzsnap0: device is busy.
INFO:         (In some cases useful info about processes that use
INFO:          the device is found by lsof(8) or fuser(1))
ERROR: command 'umount /mnt/vzsnap0' failed: exit code 1


/backup is a mounted SAMBA share.


The last lines (starting with umount) are added as soon as I hit the stop-button of the stalled backup task.


When I log in to the host I get


Code:
root@hostname:~# fuser /mnt/vzsnap0/
root@hostname:~# umount /mnt/vzsnap0
umount: /mnt/vzsnap0: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
root@hostname:~# lsof /mnt/vzsnap0
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
sh      285007 root  cwd    DIR  253,3     4096 8381789 /mnt/vzsnap0/private/106
gzip    285011 root  cwd    DIR  253,3     4096 8381789 /mnt/vzsnap0/private/106
root@hostname:~# killall -9 gzip
root@hostname:~# lsof /mnt/vzsnap0
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
sh      285007 root  cwd    DIR  253,3     4096 8381789 /mnt/vzsnap0/private/106
gzip    285011 root  cwd    DIR  253,3     4096 8381789 /mnt/vzsnap0/private/106
root@hostname:~# killall gzip
root@hostname:~# lsof /mnt/vzsnap0
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
sh      285007 root  cwd    DIR  253,3     4096 8381789 /mnt/vzsnap0/private/106
gzip    285011 root  cwd    DIR  253,3     4096 8381789 /mnt/vzsnap0/private/106


Subsequent backups on the next nights fail with


Code:
INFO: trying to get global lock - waiting...
ERROR: can't aquire lock '/var/run/vzdump.lock' - got timeout


Only a reboot of the host recovers from the error, after a reboot backups work again for about 3-4 days until the same error appears again.


Any idea what I could do to fix that?
Thanks!


Code:
root@hostname:~# pveversion -vpve-manager: 2.1-13 (pve-manager/2.1/bdd3663d)
running kernel: 2.6.32-13-pve
proxmox-ve-2.6.32: 2.1-72
pve-kernel-2.6.32-11-pve: 2.6.32-66
pve-kernel-2.6.32-13-pve: 2.6.32-72
lvm2: 2.02.95-1pve2
clvm: 2.02.95-1pve2
corosync-pve: 1.4.3-1
openais-pve: 1.1.4-2
libqb: 0.10.1-2
redhat-cluster-pve: 3.1.92-2
resource-agents-pve: 3.9.2-3
fence-agents-pve: 3.1.8-1
pve-cluster: 1.0-27
qemu-server: 2.0-47
pve-firmware: 1.0-17
libpve-common-perl: 1.0-28
libpve-access-control: 1.0-24
libpve-storage-perl: 2.0-29
vncterm: 1.0-2
vzctl: 3.0.30-2pve5
vzprocps: 2.0.11-2
vzquota: 3.0.12-3
pve-qemu-kvm: 1.1-6
ksm-control-daemon: 1.1-1
 
Last edited:
Thanks for your fast reply!
I wasnt able to figure out the default size as the man page is not very helpful here, what would be a good value?
I now set it to 80000 which should be 80GB which is a bit larger than my largest Container, good enough?

In case it should mater, here is my disk status
Code:
Filesystem             Size   Used  Avail Use% Mounted on
/dev/mapper/pve-root   102G   4.3G    93G   5% /
tmpfs                   13G      0    13G   0% /lib/init/rw
udev                    13G   234k    13G   1% /dev
tmpfs                   13G    20M    13G   1% /dev/shm
/dev/mapper/pve-data   349G   175G   175G  50% /var/lib/vz
/dev/sda1              519M    58M   435M  12% /boot
/dev/fuse               32M    21k    32M   1% /etc/pve

my config now looks like this

Code:
root@hostname:~# cat /etc/vzdump.conf
# vzdump default settings


#tmpdir: DIR
#dumpdir: DIR
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
size: 80000
#maxfiles: N
#script: FILENAME
#exclude-path: PATHLIST
 
Last edited:
Followup: WIth the previous setting, backups where not successfull as the LVM could not be created (lack of disk space).
I´ve reduced the value to as low as 5000 and at least the manual backup now works, although it just feels strange to me that it works with such a low image size (the particular container i tested with is using a 30 GB HDD)

Is there any documentation where I could read what this parameter does exactly?
 
Thanks for the explanation.
Unfortunately that didnt help, the backup tonight was again unsuccessfull

Code:
[COLOR=#000000][FONT=tahoma]INFO: starting new backup job: vzdump 101 104 106 108 --quiet 1 --mode snapshot --compress gzip --storage backup[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: filesystem type on dumpdir is 'cifs' -using /var/tmp/vzdumptmp152231 for temporary files[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: Starting Backup of VM 101 (openvz)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: CTID 101 exist mounted running[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: status = running[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: backup mode: snapshot[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: ionice priority: 7[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: creating lvm snapshot of /dev/mapper/pve-data ('/dev/pve/vzsnap-root100-0')[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO:   Logical volume "vzsnap-root100-0" created[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: creating archive '/backup/vms/dump/vzdump-openvz-101-2012_08_06-05_00_03.tar.gz'[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: Total bytes written: 622161920 (594MiB, 9.9MiB/s)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: archive file size: 254MB[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: delete old backup '/backup/vms/dump/vzdump-openvz-101-2012_08_04-05_00_01.tar.gz'[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: Finished Backup of VM 101 (00:01:09)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: Starting Backup of VM 104 (qemu)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: status = running[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: backup mode: snapshot[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: ionice priority: 7[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO:   Logical volume "vzsnap-root100-0" created[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: creating archive '/backup/vms/dump/vzdump-qemu-104-2012_08_06-05_01_12.tar.gz'[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: adding '/backup/vms/dump/vzdump-qemu-104-2012_08_06-05_01_12.tmp/qemu-server.conf' to archive ('qemu-server.conf')[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: adding '/mnt/vzsnap0/images/104/vm-104-disk-1.qcow2' to archive ('vm-disk-ide0.qcow2')[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: Total bytes written: 21172455936 (14.78 MiB/s)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: archive file size: 13.92GB[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: delete old backup '/backup/vms/dump/vzdump-qemu-104-2012_08_04-05_01_13.tar.gz'[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: Finished Backup of VM 104 (00:22:50)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: filesystem type on dumpdir is 'cifs' -using /var/tmp/vzdumptmp152231 for temporary files[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: Starting Backup of VM 106 (openvz)[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: CTID 106 exist mounted running[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: status = running[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: backup mode: snapshot[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: ionice priority: 7[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: creating lvm snapshot of /dev/mapper/pve-data ('/dev/pve/vzsnap-root100-0')[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO:   Logical volume "vzsnap-root100-0" created[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: creating archive '/backup/vms/dump/vzdump-openvz-106-2012_08_06-05_24_02.tar.gz'[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO: Total bytes written: 25170503680 (24GiB, 9.4MiB/s)[/FONT][/COLOR]

and, again after I stopped the backup task manually

Code:
[COLOR=#000000][FONT=tahoma]INFO: umount: /mnt/vzsnap0: device is busy.[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO:         (In some cases useful info about processes that use[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]INFO:          the device is found by lsof(8) or fuser(1))[/FONT][/COLOR]
[COLOR=#000000][FONT=tahoma]ERROR: command 'umount /mnt/vzsnap0' failed: exit code 1[/FONT][/COLOR]

After such unsuccessful tries my IO delay goes up to 25% and stays there until reboot...
Any further ideas?
 
Last edited:
Hm, wouldn´t call that "full"

Code:
root@hostname:~# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  pve    1   4   0 wz--n- 465.15g 11.11g

But I guess I need to check it while the backup is running?
As said, a manual backup works fine.
Would it help to split the backups up in multiple jobs?

Even strange, my server is at a constant load of 2.0 (and the high IO delay) since the backup failed, although htop gives no clue which process is eating the cpu cycles...

htop.jpg
 
Even strange, my server is at a constant load of 2.0 (and the high IO delay) since the backup failed, although htop gives no clue which process is eating the cpu cycles...

Oh sorry, I gave you the wrong command. You need to use

# lvs

or

# lvdisplay

to show snapshot status.

Seems the snapshot is still active (that is why the system is slow). Try to remove manually with:

# lvremove /dev/pve/vzsnap-root100-0

Does it work if you use a local disk as backup target?

 
Just a followup:

All methods descriped above unfortunately did not work, lvremove was not able to remove the volume either.
monitoring during the backup did not show any issues as well.

HOWEVER

I changed the compression settings from gzip to lgo and since 4 days the backups work fine now,
so there seems to be an issue with the gzip compression / the binary. However lgo works for me as well, so Im fine for now,

Thanks for all your ideas though Dietmar!
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!