Proxmox VE

SSH Transfer

SSH Transfer strategy:

• supports Proxmox 5.0+

• supports only QCOW2 disk images

• supports incremental backups

• supports over iSCSI

Backup is done by transferring QCOW2 disk images over SSH directly from the hypervisor (optionally using Netcat for transfer). Metadata is backed up only in the full backup. This method supports incremental backups where the last snapshot is required for the next incremental backups. The resulting backup has separate files for each disk + metadata, so you have the option to exclude specific drives as well.

Backup Process

• QCOW2 - file-based storage only

• crash-consistent snapshots created using hypervisor CLI over SSH

• optionally FS freeze can be executed before snapshot can be executed (FS thaw once the snapshot is completed) if enabled and guest tools installed inside

• QCOW2 snapshots mounted locally on the hypervisor and exported via SSH (optionally with netcat)

• for incremental backups, both last and currently created snapshots are mounted and block-difference is sent via SSH

• metadata exported via SSH • restore imports metadata and overwrites empty disks with data from a merged backup over SSH

Export storage repository

The Proxmox virtual environment requires you to create storage used for VM export. Export storage should also be accessible to Storware Backup & Recovery Node in its staging directory. This implies that storage space doesn't have to be exported by Storware Backup & Recovery Node - it can be mounted from an external source. The only requirement is to have it visible from both Proxmox VE hosts and the Node itself. Keep in mind that ownership of the files on the share should allow both Storware Backup & Recovery and Proxmox VE to read and write files.

Backup Process

• native VM export is done to the prepared NFS storage (staging space on Storware Backup & Recovery) using SSH access to the hypervisor

• crash-consistency - FS freeze used for VMs, LVM snapshot for containers

• optional application consistency using pre/post export command execution for VMs (pre/post snapshot) for containers

• data and metadata are in a single VMA image

• only full backups are supported • restore imports VMA image to the hypervisor

How to set up export storage repository backup

Proxmox virtual environments require backup storage to be defined on each server. This storage must be a location accessible from Storware Backup & Recovery Node (the simplest setup, when you use only 1 node, is to create NFS share for the staging path on Storware Backup & Recovery Node)

1. Create storage from NFS share (Content-type: only VZDump)

• Export share must be set to use the UID and GID of the vprotect user

• Example export configuration in /etc/exports to the selected hypervisor in the cluster:

  /vprotect_data    PROXMOX_HOSTS(fsid=6,rw,sync,insecure,all_squash,
  anonuid=993,anongid=990)

  where anonuid=993 and anongid=990 should have correct UID and GID returned by command:

  [root@vProtect3 ~]# id vprotect
  uid=993(vprotect) gid=990(vprotect) groups=990(vprotect)

• Both import and export operations will be done using these NFS shares – restore will be done directly to this storage domain, so you can easily import the backup into Proxmox VE

  • backups must be restored to the export path (the node automatically changes names to the original paths that are recognized by Proxmox VE.

• A name for storage must be provided later in the node configuration (Hypervisor -> Proxmox section)

File-level restore support for VMA images

Prepare the VMA extractor on Storware Backup & Recovery Node - you have 2 options:

• build VMA extractor like this (requires Internet on the node):

cd /opt/vprotect/node/scripts/vma
./setup_vma.sh

• download VMA extractor from Storware repository and install it

cd /opt/vprotect/node/scripts/vma
./setup_vma.sh PATH_TO_VMA_ARCHIVE

Supported features

	Export storage repository	SSH transfer (preferred)
Supported versions	5.2, 5.3, 5.4, 6.0, 6.1, 6.2, 6.3, 6.3, 6.4, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2, 8.3, 8.4	5.2, 5.3, 5.4, 6.0, 6.1, 6.2, 6.3, 6.3, 6.4, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2, 8.3, 8.4
The last snapshot is kept on the hypervisor for incremental backups	No	Yes
Access to hypervisor OS required	Yes	Yes
Proxy VM required	No	No

	Export storage repository	SSH transfer
Full backup	Supported	Supported
Incremental backup	Not supported	Supported
Restore	Supported	Supported
File-level restore	Supported	Supported
VM disk exclusion	Not supported	Supported
Quiesced snapshots	Supported	Supported
Snapshots management	Supported	Supported
Pre/post command execution	Supported	Supported
Access to VM disk backup over iSCSI	Not supported	Supported
VM name-based policy assignment	Supported	Supported
VM tag-based policy assignment	Not supported	Not supported
Power-on VM after restore	Supported	Supported

Network requirements

Export storage repository

Source	Destination	Ports	Description
Node	Hypervisor	22/tcp	SSH access
Hypervisor	Node	If Node is hosting staging space: 111/tcp, 111/UDP, 2049/tcp, 2049/UDP, ports specified in /etc/sysconfig/nfs - variables MOUNTD_PORT (TCP and UDP), STATD_PORT (TCP and UDP), LOCKD_TCPPORT (TCP), LOCKD_UDPPORT (UDP), otherwise please check the documentation of your NFS storage provider	NFS access
Node and hypervisor	shared NFS storage	check the documentation of your NFS storage provider	if staging space (export storage domain) is hosted on the shared storage - NFS access

SSH Transfer

Source	Destination	Ports	Description
Node	Hypervisor	22/tcp	SSH access