Increasing backup storage area

Diablo

New Member
Jan 28, 2010
17
0
1
Hi,

I have two VM's running and am trying to back them both up.

Both VM's have 400Gb assigned to them.
One VM uses about 10Gb at the moment the other uses about 50Gb

Here is the /etc/cron.d/vzdump file content:

# Atomatically generated file - do not edit
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
00 20 * * 1,2,3,4,5 root vzdump --quiet --node 1 --snapshot --compress --storage VM-backups --mailto email@mycompany.com 101 102

VM 101 backs up fine but VM 102 fails everytime.

Here is the error that vzdump returns

102: Mar 12 22:10:21 INFO: Starting Backup of VM 102 (qemu)
102: Mar 12 22:10:21 INFO: running
102: Mar 12 22:10:21 INFO: status = running
102: Mar 12 22:10:21 INFO: backup mode: snapshot
102: Mar 12 22:10:21 INFO: bandwidth limit: 10240 KB/s
102: Mar 12 22:10:22 INFO: Logical volume "vzsnap-CENHNS-001-0" created
102: Mar 12 22:10:22 INFO: creating archive '/VMbackup//vzdump-qemu-102-2010_03_12-22_10_21.tgz'
102: Mar 12 22:10:22 INFO: adding '/VMbackup//vzdump-qemu-102-2010_03_12-22_10_21.tmp/qemu-server.conf' to archive ('qemu-server.conf')
102: Mar 12 22:10:22 INFO: adding '/dev/drbdvg/vzsnap-CENHNS-001-0' to archive ('vm-disk-ide0.raw')
102: Mar 13 21:16:48 INFO: 93969731584 B 87.5 GB 83186.7 s (23:06 h) 1129625 B/s 1.08 MB/s
102: Mar 13 21:16:48 INFO: write: No space left on device
102: Mar 13 21:16:48 INFO: received signal - terminate process
102: Mar 13 21:16:50 INFO: Logical volume "vzsnap-CENHNS-001-0" successfully removed
102: Mar 13 21:19:00 ERROR: Backup of VM 102 failed - command '/usr/lib/qemu-server/vmtar '/VMbackup//vzdump-qemu-102-2010_03_12-22_10_21.tmp/qemu-server.conf' 'qemu-server.conf' '/dev/drbdvg/vzsnap-CENHNS-001-0' 'vm-disk-ide0.raw' |gzip |cstream -t 10485760 >/VMbackup//vzdump-qemu-102-2010_03_12-22_10_21.dat' failed with exit code 2

I have created a local directory to store the backups in. But although i have 500Gb available on my proxmox installation drive, proxmox reports only to have 94Gb "HD space root" size available and only 89Gb for my backup folder under the storage area in the web interface.

Is there anyway to increase the size of either the "HD space root" or the backup directory folder?

Also is the almost 24 hour runtime for the backup normal or is this due to the fact that it is running out of space?
 
Last edited:
as you use snapshots the backup destination cannot reside on the volume group data, only in root. think of doing backup to remote host, e.g. NFS server.
 
Tom thanks for your reply.

To bad the root can not be increased. i have a 500Gb disk which is mostly not used now. (or so it seems)
The VM's are running with DRBD on a raid set. so I was hoping to utelise the 500Gb where Promox is installed as backup area and copy them from there to where needed.

Can I backup to another server without creating a NFS server?
And what about the time of the backup, normal or caused by lack of space?
 
Tom thanks for your reply.

To bad the root can not be increased.

I do not say that is not possible, its just a LVM, so feel free to change the sizes. so you need to shrink the data and extend the root.
 
as you use snapshots the backup destination cannot reside on the volume group data, only in root

Why snapshotting isn't done when i configure the backup storage on LV "data" ? I don't see an evident technical reason; "root" and "data" are both LV on the same "pve" VG , and default "data" size is about three times "root" ...

rob
 
What about putting in the log of "vzdump --snapshot" something like:

"Can't use snapshot mode when destination storage is on the same Logical Volume we are snapshotting from - passing to suspend mode."

rob
 
What is wrong with the current hint?

I retried and finally saw:

"
INFO: mode failure - unable to dump into snapshot (use option --dumpdir)
INFO: trying 'suspend' mode instead
"
I apologize, definitely I should had to read more carefully :-(

Anyway maybe a "WARNING:" instead of an "INFO" could help to point out that two lines.

Furthermore, silently applying a "suspend" instead of a "snapshot" results in an unexpected unavailability of the vm,
and probably the administrator should be warned beforehand (when setting a backup schedule, for example)

rob
 
Last edited:
I do not say that is not possible, its just a LVM, so feel free to change the sizes. so you need to shrink the data and extend the root.

Ok, I have shrunk the data from 390 to 150 Gb but now how do I extend the root, because the root will not unmount to do the resize?

I have shrunk the data by doing to following:

# mount
/dev/pve/root on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
/dev/mapper/pve-data on /var/lib/vz type ext3 (rw)

#umount /var/lib/vz

# e2fsck -f /dev/mapper/pve-data
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/pve-data: 20/22429696 files (0.0% non-contiguous), 1457573/89713664 blocks

# resize2fs /dev/mapper/pve-data 40000000
resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/mapper/pve-data to 40000000 (4k) blocks.
The filesystem on /dev/mapper/pve-data is now 40000000 blocks long.

#mount /dev/mapper/pve-data /var/lib/vz

I checked through the web interface and saw that the data size had indeed been decreased to about 150Gb
 
Last edited:
Tom said:
I do not say that is not possible, its just a LVM, so feel free to change the sizes. so you need to shrink the data and extend the root.


Ok, I have shrunk the data from 390 to 150 Gb but now how do I extend the root, because the root will not unmount to do the resize?

I have shrunk the data by doing to following:

# mount
/dev/pve/root on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/cciss/c0d0p1 on /boot type ext3 (rw)
/dev/mapper/pve-data on /var/lib/vz type ext3 (rw)

#umount /var/lib/vz

# e2fsck -f /dev/mapper/pve-data
e2fsck 1.41.3 (12-Oct-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/pve-data: 20/22429696 files (0.0% non-contiguous), 1457573/89713664 blocks

# resize2fs /dev/mapper/pve-data 40000000
resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/mapper/pve-data to 40000000 (4k) blocks.
The filesystem on /dev/mapper/pve-data is now 40000000 blocks long.

#mount /dev/mapper/pve-data /var/lib/vz

I checked through the web interface and saw that the data size had indeed been decreased to about 150Gb
 
Ok, I have shrunk the data from 390 to 150 Gb but now how do I extend the root, because the root will not unmount to do the resize?

boot your pve machine with a recent LVM2-aware live cd ( knoppix? ubuntu?) and do the same!

bye,
rob
 
rob said:
boot your pve machine with a recent LVM2-aware live cd ( knoppix? ubuntu?) and do the same

Thanks worked like a charm.

udo said:
you can expand a lv and the filesystem on the fly (mounted).

When i tried it wouldn't let me.


Thanks everyone for your assistance.
 

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!