how can i take over one snapshot in vm??
- Thread starter kk_proxmox
- Start date
Hi,
I would guess this isn't a feature implemented via web-interface of ProxVE yet. I'm not positive, but I suspect you can manually do things 'behind the scenes' (root ssh console on ProxVE host) to give more than one 'snapshot', ie,
- use vzdump as root to make backup copies of a OpenVZ container-based virtual host; then 'hide' your backup file in a 'secret' location (ie, not managed by ProxVE web interface, but still somewhere on the same /var/lib/vz datastore volume on your proxve host)
- then if you need to revert to a given old backup, you just stop the vhost; manually use vzdump with 'restore' option - to revert back to this state.
Similar process could be done for KVM based (fully virtualized) hosts; since your entire VHOST disk image is captured in a single .qcow2 file
as illustrated below for example:
---PASTE----
prox1:/var/lib/vz/images/101# pwd
/var/lib/vz/images/101
prox1:/var/lib/vz/images/101# ls -la
total 11516756
drwxr-xr-x 2 root root 4096 2009-05-06 18:02 .
drwxr-xr-x 5 root root 4096 2009-06-10 12:52 ..
-rw-r--r-- 1 root root 11781627904 2009-06-12 05:40 vm-101-disk.qcow2
prox1:/var/lib/vz/images/101#
---ENDPASTE_--
Note in this case VM-101 is a "32 gig" disk image running Server 2003, but since I have only used ~11gigs of data inside the VM, the qcow file is smaller than 32gigs presently.
Likely if making a backup copy of a qcow2 file, you will want to 'power off' the VM before making the copy, otherwise any active processes/ open files might be only 'crash consistent' (ie, not entirely clean)
Strictly speaking, this approach is not doing snapshots (which would be more elegant copy-on-write buffered somehow) - and thus you wouldn't incur such a disk space penalty for making 'full copies' of your VMs.
But - if you really need to have bare-metal level backup copies of your VMs, it is not difficult to get access to them.
Note if you are 'really' interested in making 'bare metal backup' of KVM info, you might also want to copy config data which is stored in /etc, for example:
---PASTE---
prox1:/etc# cd /etc/qemu-server/
prox1:/etc/qemu-server# ls -la
total 20
drwxr-xr-x 2 root root 4096 2009-06-10 12:59 .
drwxr-xr-x 70 root root 4096 2009-05-06 17:50 ..
-rw-r--r-- 1 root root 153 2009-05-13 12:35 101.conf
-rw-r--r-- 1 root root 186 2009-05-20 07:54 105.conf
-rw-r--r-- 1 root root 140 2009-06-10 12:59 106.conf
-rw-r--r-- 1 root root 0 2009-05-06 17:55 .lock-101.conf
-rw-r--r-- 1 root root 0 2009-05-20 07:54 .lock-105.conf
-rw-r--r-- 1 root root 0 2009-06-10 12:52 .lock-106.conf
prox1:/etc/qemu-server# more 101.conf
name: win-2003
ide2: none,media=cdrom
smp: 1
vlan0: rtl8139=E2:7E:9F:2F:82:FD
bootdisk: ide0
ide0: vm-101-disk.qcow2
ostype: wxp
memory: 512
onboot: 1
prox1:/etc/qemu-server#
---ENDPASTE---
clearly this is just a bit of config info for the KVM virtualized virtual host - the mac address / NIC configured / NIC type / identification of the qcow2 file, ram and CPU assigned to the host. But having this info might help if you accidentially destroyed your VM and wanted to restore it from a 'cold backup copy' that was stored elsewhere
I hope this info is of some use,
Tim Chipman
Fortech I.T. Solutions
http://FortechITSolutions.ca
I would guess this isn't a feature implemented via web-interface of ProxVE yet. I'm not positive, but I suspect you can manually do things 'behind the scenes' (root ssh console on ProxVE host) to give more than one 'snapshot', ie,
- use vzdump as root to make backup copies of a OpenVZ container-based virtual host; then 'hide' your backup file in a 'secret' location (ie, not managed by ProxVE web interface, but still somewhere on the same /var/lib/vz datastore volume on your proxve host)
- then if you need to revert to a given old backup, you just stop the vhost; manually use vzdump with 'restore' option - to revert back to this state.
Similar process could be done for KVM based (fully virtualized) hosts; since your entire VHOST disk image is captured in a single .qcow2 file
as illustrated below for example:
---PASTE----
prox1:/var/lib/vz/images/101# pwd
/var/lib/vz/images/101
prox1:/var/lib/vz/images/101# ls -la
total 11516756
drwxr-xr-x 2 root root 4096 2009-05-06 18:02 .
drwxr-xr-x 5 root root 4096 2009-06-10 12:52 ..
-rw-r--r-- 1 root root 11781627904 2009-06-12 05:40 vm-101-disk.qcow2
prox1:/var/lib/vz/images/101#
---ENDPASTE_--
Note in this case VM-101 is a "32 gig" disk image running Server 2003, but since I have only used ~11gigs of data inside the VM, the qcow file is smaller than 32gigs presently.
Likely if making a backup copy of a qcow2 file, you will want to 'power off' the VM before making the copy, otherwise any active processes/ open files might be only 'crash consistent' (ie, not entirely clean)
Strictly speaking, this approach is not doing snapshots (which would be more elegant copy-on-write buffered somehow) - and thus you wouldn't incur such a disk space penalty for making 'full copies' of your VMs.
But - if you really need to have bare-metal level backup copies of your VMs, it is not difficult to get access to them.
Note if you are 'really' interested in making 'bare metal backup' of KVM info, you might also want to copy config data which is stored in /etc, for example:
---PASTE---
prox1:/etc# cd /etc/qemu-server/
prox1:/etc/qemu-server# ls -la
total 20
drwxr-xr-x 2 root root 4096 2009-06-10 12:59 .
drwxr-xr-x 70 root root 4096 2009-05-06 17:50 ..
-rw-r--r-- 1 root root 153 2009-05-13 12:35 101.conf
-rw-r--r-- 1 root root 186 2009-05-20 07:54 105.conf
-rw-r--r-- 1 root root 140 2009-06-10 12:59 106.conf
-rw-r--r-- 1 root root 0 2009-05-06 17:55 .lock-101.conf
-rw-r--r-- 1 root root 0 2009-05-20 07:54 .lock-105.conf
-rw-r--r-- 1 root root 0 2009-06-10 12:52 .lock-106.conf
prox1:/etc/qemu-server# more 101.conf
name: win-2003
ide2: none,media=cdrom
smp: 1
vlan0: rtl8139=E2:7E:9F:2F:82:FD
bootdisk: ide0
ide0: vm-101-disk.qcow2
ostype: wxp
memory: 512
onboot: 1
prox1:/etc/qemu-server#
---ENDPASTE---
clearly this is just a bit of config info for the KVM virtualized virtual host - the mac address / NIC configured / NIC type / identification of the qcow2 file, ram and CPU assigned to the host. But having this info might help if you accidentially destroyed your VM and wanted to restore it from a 'cold backup copy' that was stored elsewhere
I hope this info is of some use,
Tim Chipman
Fortech I.T. Solutions
http://FortechITSolutions.ca