How to Backup OpenVZ containers (VM’s) using vzdump on Centos / RHEL

Post Date: October 11, 2018
Last Updated: September 28, 2026

Introduction

This guide explains how to back up OpenVZ containers using vzdump on CentOS/RHEL. vzdump isn’t included in the standard OpenVZ repository for CentOS/RHEL — you either compile it from source yourself, or install it from a third-party repository, covered below.

Two things worth knowing upfront: this guide applies to legacy OpenVZ (the vzctl/CTID-based tooling shown below), not OpenVZ 7 or Virtuozzo, which use different commands (prlctl). And standard CentOS Linux itself has reached end-of-life (CentOS 7 in June 2024, CentOS 8 in December 2021) — if you’re setting up a new hardware node today, consider a currently supported alternative like AlmaLinux, Rocky Linux, or CentOS Stream instead.

Prerequisites

• A hardware node running legacy OpenVZ, with one or more containers (VMs) configured
• Root access to the hardware node

Architecture

• vzdump reads each container’s filesystem and configuration directly from the hardware node
• It packages that data into a compressed archive (.tgz) per container
• The archive can later be restored to the same or a different CTID using vzrestore

Steps

I. Install vzdump

vzdump isn’t in the standard OpenVZ repo, so it needs to come from a third-party source — historically, the SolusVM/SolusLabs repository has provided it.

Create the repo file:

cd /etc/yum.repos.d
vi solusvm.repo

Add:

[soluslabs]
name=Soluslab Repo
mirrorlist=http://repo.soluslabs.com/centos/mirrors-soluslabs
gpgcheck=0
enabled=1

Security note: gpgcheck=0 disables package signature verification entirely, meaning packages from this repo aren’t cryptographically verified before installing — a real risk if the repository or its mirror were ever compromised. If this repository provides a GPG key, import it and set gpgcheck=1 instead. Also verify this repository is still actively maintained before relying on it; third-party repos like this can go stale or disappear over time. If it’s unavailable, compiling vzdump from source (as OpenVZ’s own documentation covers) is the more durable fallback.

Install it:

yum install vzdump

II. List Your Current Containers

vzlist -a

Example output:

 CTID  NPROC   STATUS    IP_ADDR         HOSTNAME
101   338    running  192.168.0.101  server1.example.com
102   -      stopped  192.168.0.102  server2.example.com
103   -      stopped  192.168.0.103  server3.example.com

III. Create the Backup Directory

mkdir /home/backup
chmod 700 /home/backup
chown root:root /home/backup

Use any path you prefer — just confirm it has enough free space for your containers’ full backups.

IV. Back Up a Single Container

vzdump --compress --dumpdir /home/backup 101

--compress stores the backup as .tar.gz to save space.

V. Back Up All Containers on the Node

vzdump --compress --dumpdir /home/backup --all

VI. Restore a Backup to a Different Container

vzrestore /home/backup/vzdump-101.tgz 103

This restores the backup from container 101 into a new container with CTID 103. See man vzrestore for additional options.

VII. Test Your Backups Periodically

An untested backup only gives false confidence. Periodically restore a backup to a spare CTID to confirm it actually works end to end, rather than assuming it does because the vzdump command completed without errors.

Conclusion

Backing up OpenVZ containers with vzdump comes down to installing it (since it isn’t in the standard repo), then running it against a single container or all of them with --dumpdir pointing at your backup location. Just weigh the third-party repo’s gpgcheck=0 setting and long-term availability against compiling from source if you want a more verifiable installation path — and remember this applies specifically to legacy OpenVZ, not OpenVZ 7/Virtuozzo.

Frequently Asked Questions

Does this work with OpenVZ 7 or Virtuozzo? No — this guide covers legacy OpenVZ (vzctl/CTID-based). OpenVZ 7 and Virtuozzo use prlctl and a different toolset entirely.

Is it safe to leave gpgcheck=0 in the repo file long-term? Not ideal — it means packages from that repo are never signature-verified. If a GPG key is available for the repo, import it and switch to gpgcheck=1 instead.

How do I automate this on a schedule? Add the vzdump --compress --dumpdir ... --all command to a cron job, and consider copying the resulting archives off the hardware node afterward, so a full node failure doesn’t take your only backup copy with it.

Related Articles

How to restore OpenVZ / Virtuozzo 7 (Disaster Recovery – DR)

How to Create an OpenVZ Container via Bash Script?

Talk to Our Technology Experts

Managing virtualization infrastructure or need a reliable backup strategy? Our team can help with server administration, backup automation, and ongoing infrastructure support.

Connect with our technology experts.