Proxmox Backup Strategy and 'Snapshot' Weirdness
-
I've been poking around with proxmox for the last few days and have had some success with the backup and restore process. My setup is simple. Dell T320 this hardware raid, a 2tb raid one set, 16 gig of ram running proxmox 6.2 with community subscription. Created a Server 16 guest on a 32 Gig boot drive using the local-lvm storage option , tested and works fine. Subsequently added a second virtual disk for data, also using the local-lvm option. Added some data and began backing up to a samba share running on a separate physical machine. The backup went well, as well as the subsequent restore.
But along the way things got weird.
In setting up the backup job the choices for mode are snapshot, suspend, and stop. The snapshot mode confused me because the term snapshot is also used to create what I will call a 'state' snapshot rather than a 'real' backup. In this case I thought that the snapshot mode of a backup would create an incremental backup - but it did not. I wound up with another full backup.
The test vm just described has a total of 70 gig disk space on the two drives and the backup process takes about 17 minutes on my current hardware. So does the restore process. BUT, my goal is to backup a server that has 1.4 TB of data and also have a maximum recovery time of 4 hours. . I suspect that the full backup and restore process for a data set this large will not meet the recovery objective.
So here I sit, trying to find a way to create incremental backups from the proxmox web gui or using a third party tool. In the meanwhile one thought I have is create a periodic backup of the boot drive from the proxmox gui, and then have another process run from within the vm to make full and incremental backups of the data.
So how are other Proxmox users managing their backup and recovery.
-
@ronneyb said in Proxmox Backup Strategy and 'Snapshot' Weirdness:
The snapshot mode confused me because the term snapshot is also used to create what I will call a 'state' snapshot rather than a 'real' backup.
All VM level backup solutions make use of snapshots to backup running machines. This is how it is supposed to work.
No a snapshot by itself is not a backup. But once you copy the virtual disk off that is no longer being written to because of the snapshot process, along with the associated VM settings, now you have a backup.
-
@ronneyb said in Proxmox Backup Strategy and 'Snapshot' Weirdness:
the backup job the choices for mode are snapshot, suspend, and stop.
First what do you need to have a successful backup? A copy of the system when nothing is being written to it.
Think then a little. What do those names mean.
Stop: the virtual machine is stopped. The power is off, via guest shutdown normally. But forced off if needed.
Suspend: the virtual machine is put into hibernation.
Snapshot: the virtual machine stays running but disks stop being written to. All new changes are written to a new virtual disk files.
-
I'm only using Proxmox at home and I mainly use it on my lxc containers and small qemu VMs like MeshCentral and VitalPBX. I'm ZSTD compression and snapshot mode.
If you want incremental backups, data de-duplication, compression and encryption, there's a BETA release of Proxmox Backup Server (https://pbs.proxmox.com/wiki/index.php/Main_Page)
-
@JaredBusch Thanks Jared - the snapshot issue is ow clear in my mind
-
@black3dynamite - going there no - will try it and see how it works
-
@ronneyb said in Proxmox Backup Strategy and 'Snapshot' Weirdness:
The snapshot mode confused me because the term snapshot is also used to create what I will call a 'state' snapshot rather than a 'real' backup.
We use the standard ProxMox backups. You don't get a powerful incremental function, but the cost (zero) offsets that compared to the cost of storage for us most of the time. It's rare that we are backing up a giant system, and full backups have their advantages. So mostly we just can overlook the lack of incrementals, just not important.
If you really need them, I'd recommend a different tool. Or you can theoretically approximate them using a powerful compression and deduping location for the storage.
