Difference between revisions of "Backup of a running container with vzdump"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
m (Download)
m (Reverted edits by StevenCook (talk) to last revision by Kir)
 
(16 intermediate revisions by 9 users not shown)
Line 10: Line 10:
  
 
== Download ==
 
== Download ==
Download vzdump rpm or deb packages from http://download.openvz.org/contrib/utils/vzdump/ or for newest version, check http://download.proxmox.com.
+
Download vzdump rpm or deb packages from http://download.openvz.org/contrib/utils/vzdump/ or for newest version, check http://download.proxmox.com/debian/dists/lenny/pve/binary-amd64/ .
  
 
For Debian based systems:
 
For Debian based systems:
<pre>wget http://download.proxmox.com/debian/dists/lenny/pve/binary-amd64/vzdump_1.2-7_all.deb</pre>
+
<pre>wget http://download.proxmox.com/debian/dists/lenny/pve/binary-amd64/vzdump_1.2-16_all.deb</pre>
  
  
Line 23: Line 23:
  
 
For Debian based systems:
 
For Debian based systems:
<pre>dpkg -i vzdump_1.2-5_all.deb</pre>
+
<pre>dpkg -i vzdump_1.2-16_all.deb</pre>
  
 
== Synopsis ==
 
== Synopsis ==
Line 80: Line 80:
  
 
Note that using LVM2 and vzdump to create snapshots requires 512Mb of free space in your VG as described  [http://weblogs.amtex.nl/index.php?blog=2&title=using_vzdump_snapshot_to_backup_without_downtime&more=1&c=1&tb=1&pb=1 here].
 
Note that using LVM2 and vzdump to create snapshots requires 512Mb of free space in your VG as described  [http://weblogs.amtex.nl/index.php?blog=2&title=using_vzdump_snapshot_to_backup_without_downtime&more=1&c=1&tb=1&pb=1 here].
 +
 +
=== Set-up LVM ===
 +
While the LVM solution is the cleanest, since it allows to create an online backup without having to stop or suspend the virtual machine, it is also the hardest to set up. There are a few dependencies you should be aware of before setting up your LVM:
 +
 +
* You need to have at least 512MB free in your LVM volume group, to be able to create snapshots
 +
* The directory where you are writing your backup dumps to (usually <code>/vz/dump</code>) should be on a different volume group than the one you are taking a backup from (usually <code>/vz/private</code>)
 +
* There is a bug in <code>VZDump.pm</code> that can make the snapshot creation fail
 +
 +
==== Partitioning ====
 +
As described above, you need to keep a few things in mind when creating your LVM partitions. In the example setup below, there are a total of 4 partitions:
 +
 +
* <code>/</code>, which is hosting the default OS files, on a 10GB LVM logical volume
 +
* <code>/boot</code>, which is hosting the kernel and bootloader config, on a 512MB standard Linux partition
 +
* <code>/opt</code>, which is hosting the backup dump files, on a 100GB LVM logical volume
 +
* <code>/vz</code>, which is hosting all virtual machine files, on a 1.6TB LVM logical volume
 +
 +
All logical volumes are hosted on a 1.8TB volume group of which only 1.7TB is used by the above partitions and 100GB is unallocated.
 +
 +
In this setup the 100GB of free volume group space and 100GB of backup directory have been chosen to hold the snapshots and tar files that will be created when the virtual machine will be backed up. As specified above, only 512MB of snapshot space is needed, but it's better to be safe than having to resize your volumes at a later stage when disk space is not an issue. The same holds for the backup directory.
 +
 +
==== Fixing VZDump.pm ====
 +
When trying to backup a virtual machine, creation of the snapshot can fail. This is because of a bug in <code>VZDump.pm</code>. In CentOS (and other RHEL derivatives), this file is located in <code>/usr/share/perl5/PVE/VZDump.pm</code>.
 +
 +
On line 622, you will find the following:
 +
 +
if ($line =~ m|^\s*(\S+):(\S+):(\d+(\.\d+))M$|) {
 +
 +
Replace this with:
 +
 +
if ($line =~ m|^\s*(\S+):(\S+):(\d+([\.,]\d+))[mM]$|) {
 +
 +
Save and close the file. Snapshots will now work with <code>vzdump</code>
 +
 +
==== Example ====
 +
Since in the above example we have relocated the dump directory, you will need to run backups with a command similar to the following:
 +
 +
vzdump --dumpdir /opt/backupdir --snapshot 101
  
 
=== Restore ===
 
=== Restore ===
Line 88: Line 125:
 
OR
 
OR
 
  vzdump --restore /space/backup/vzdump-777.tar 600
 
  vzdump --restore /space/backup/vzdump-777.tar 600
 +
 +
Note : vzdump --restore is not present in version 1.2-7, use vzrestore instead.
  
 
== Bugs ==
 
== Bugs ==
Line 123: Line 162:
 
Other distributions or versions may be affected, too.
 
Other distributions or versions may be affected, too.
  
 +
<!--
 +
link dead
 
== Hooks ==
 
== Hooks ==
  
 
http://nachtmann.it/blog/vzdump-hook-ftp-backup-script - Backup to FTP with limited capacity
 
http://nachtmann.it/blog/vzdump-hook-ftp-backup-script - Backup to FTP with limited capacity
 
+
-->
 
[[Category: HOWTO]]
 
[[Category: HOWTO]]

Latest revision as of 20:46, 4 August 2012

Vzdump is a utility to make consistent snapshots of running OpenVZ containers (and KVM virtual machines if you are using Proxmox VE). It basically creates a tar archive of the container's private area, which also includes the CT configuration files.

There are several ways to provide consistency:

  • Stop the CT during backup (very long downtime)
  • Use rsync and suspend/resume (minimal downtime)
  • Use LVM2 (no downtime)

Vzdump stores the backup on the disk in a single file. This file should go to a tape backup for archiving.

Download[edit]

Download vzdump rpm or deb packages from http://download.openvz.org/contrib/utils/vzdump/ or for newest version, check http://download.proxmox.com/debian/dists/lenny/pve/binary-amd64/ .

For Debian based systems:

wget http://download.proxmox.com/debian/dists/lenny/pve/binary-amd64/vzdump_1.2-16_all.deb


For future versions, Proxmox will not release rpm´s, so you need to take a look at the sources. (maybe someone else can maintain vzdump rpm packages?)

Installation[edit]

For rpm based systems:

rpm -i vzdump-1.2-5.noarch.rpm

For Debian based systems:

dpkg -i vzdump_1.2-16_all.deb

Synopsis[edit]

see also:

man vzdump

vzdump OPTIONS [--all | <VMID>]

      --exclude VMID          exclude VMID (assumes --all)
      --exclude-path REGEX    exclude certain files/directories. You
                              can use this option more than once to specify
                              multiple exclude paths
      --stdexcludes           exclude temporary files and logs
      --compress              compress dump file (gzip)
      --storage STORAGE_ID    store resulting files to STORAGE_ID (PVE only)
      --script                execute hook script
      --dumpdir DIR           store resulting files in DIR
      --maxfiles N            maximal number of backup files per VM.
      --tmpdir DIR            store temporary files in DIR. --suspend and --stop
                              are using this directory to store a copy of the VM.
      --mailto EMAIL          send notification mail to EMAIL. You can use
                              this option more than once to specify multiple
                              receivers
      --stop                  stop/start VM if running
      --suspend               suspend/resume VM when running
      --snapshot              use LVM snapshot when running
      --size MB               LVM snapshot size (default 1024)
      --bwlimit KBPS          limit I/O bandwidth; KBytes per second
      --lockwait MINUTES      maximal time to wait for the global
                              lock. vzdump uses a global lock file to make
                              sure that only one instance is running
                              (running several instance puts too much load
                              on a server). Default is 180 (3 hours).
      --stopwait MINUTES      maximal time to wait until a VM is stopped.

Examples[edit]

Use a running container, for example install this: Proxmox Mail Gateway in container.

Backup[edit]

Simply dump CT 777 — no snapshot, just archive the container private area and configuration files to the default dump directory (usually /vz/dump/).

vzdump 777

Use rsync and suspend/resume to create a snapshot (minimal downtime).

vzdump --suspend 777

Backup all containers and send notification mails to root.

vzdump --suspend --all --mailto root

Use LVM2 to create snapshots (no downtime).

vzdump --dumpdir /space/backup --snapshot 777

Note that using LVM2 and vzdump to create snapshots requires 512Mb of free space in your VG as described here.

Set-up LVM[edit]

While the LVM solution is the cleanest, since it allows to create an online backup without having to stop or suspend the virtual machine, it is also the hardest to set up. There are a few dependencies you should be aware of before setting up your LVM:

  • You need to have at least 512MB free in your LVM volume group, to be able to create snapshots
  • The directory where you are writing your backup dumps to (usually /vz/dump) should be on a different volume group than the one you are taking a backup from (usually /vz/private)
  • There is a bug in VZDump.pm that can make the snapshot creation fail

Partitioning[edit]

As described above, you need to keep a few things in mind when creating your LVM partitions. In the example setup below, there are a total of 4 partitions:

  • /, which is hosting the default OS files, on a 10GB LVM logical volume
  • /boot, which is hosting the kernel and bootloader config, on a 512MB standard Linux partition
  • /opt, which is hosting the backup dump files, on a 100GB LVM logical volume
  • /vz, which is hosting all virtual machine files, on a 1.6TB LVM logical volume

All logical volumes are hosted on a 1.8TB volume group of which only 1.7TB is used by the above partitions and 100GB is unallocated.

In this setup the 100GB of free volume group space and 100GB of backup directory have been chosen to hold the snapshots and tar files that will be created when the virtual machine will be backed up. As specified above, only 512MB of snapshot space is needed, but it's better to be safe than having to resize your volumes at a later stage when disk space is not an issue. The same holds for the backup directory.

Fixing VZDump.pm[edit]

When trying to backup a virtual machine, creation of the snapshot can fail. This is because of a bug in VZDump.pm. In CentOS (and other RHEL derivatives), this file is located in /usr/share/perl5/PVE/VZDump.pm.

On line 622, you will find the following:

if ($line =~ m|^\s*(\S+):(\S+):(\d+(\.\d+))M$|) {

Replace this with:

if ($line =~ m|^\s*(\S+):(\S+):(\d+([\.,]\d+))[mM]$|) {

Save and close the file. Snapshots will now work with vzdump

Example[edit]

Since in the above example we have relocated the dump directory, you will need to run backups with a command similar to the following:

vzdump --dumpdir /opt/backupdir --snapshot 101

Restore[edit]

Restore the above backup to CT 600:

vzrestore /space/backup/vzdump-777.tar 600

OR

vzdump --restore /space/backup/vzdump-777.tar 600

Note : vzdump --restore is not present in version 1.2-7, use vzrestore instead.

Bugs[edit]

(not fixed in 1.2-4) The rsync command used by vzdump to create the backup in suspend mode partially ignores the "--exclude-path" option. In fact, even if the excluded paths won't appear in the final output, the whole VPS will be moved to the temporary directory, meaning that you need as much free disk space as your VPS size to use vzdump. It can be an issue in the case of a file server handling many files...

Workaround: A workaround has been proposed on OpenVZ forum, see below for the excerpt. (http://forum.openvz.org/index.php?t=msg&goto=36924&)

User: tatawaki
Messages: 3
Registered: December 2008  Junior Member
From: *sbm.shawcable.net

Line 694:
my $rsyncopts = "--stats --numeric-ids --bwlimit=${opt_bwlimit}";

# changes to

my $rsyncopts = "--stats --numeric-ids --bwlimit=${opt_bwlimit}";
$rsyncopts = $rsyncopts." --exclude-from=/home/backups/exclude_vzdump.txt";

the txt file contains <VEID>/home/:

1094/home/
510/opt/
...

(fixed in 1.1-1) vzdump will fail under Debian Etch in version 1.0-2 if it is invoked with parameter "--snapshot" and if the logical volume name contains a hyphen.

Workaround: One possible workaround is to rename the logical volume in question thus it doesn't contain any hyphen. A bug report was sent to proxmox on 02 June 2008. Other distributions or versions may be affected, too.