I have a network file share that I would like to use to archive old containers and virtual machines. What is the best way to go about this in Proxmox. For example, I have a VM (104) and a container (105) that I would like to archive so I can restore them later if necessary but they don't need to be listed on the server anymore. I looked at using backups for this, but they don't seem like the right approach. Instead, I almost want an archive feature that saves everything, just like a backup but also removes it from the server afterwards, freeing up resources on the server.
[SOLVED] Archiving old containers and VMs?
- Thread starter Tom Moyer
- Start date
Apologies if it's considered bad form here to resurrect an old thread.. I'm considering the suggested approach to "archive" VM's that are used rarely, but thinking it through, while perhaps workable, it feels a little incomplete and perhaps prone to user error.
Let's say I "archive" a machine by backing it up, and then deleting it.
Later I need to restore the machine temporarily, perhaps make some changes and archive it again..
First I need to identify the correct "archive" backup somehow (verifying it doesn't belong to an existing machine, but rather the correct one that I "archived" and deleted previously)
It's likely the old vmid has been recycled and is now in use again, so the newly restored machine gets a different vmid now
I make the required changes, and then back up the new machine, but with the new vmid, presumably the backup chain is now broken. I also need to be sure that the backup retention policy isn't stupid and end up pruning the only copy. (actually, this makes me wonder now how long term backups are managed in the event a vmid is recycled, that could be another cause for confusion)
That already feels like enough bookkeeping to prevent me from adopting this type of "archive" arrangement, and so the easier/safer option is to just leave the VM where it is, not running and not benefitting from any kind of compression/deduplication (while also being needlessly included in any regular backup cycle)
Would there be merit in developing the concept of an archive/deepfreeze model as a supported first class feature?
Let's say I "archive" a machine by backing it up, and then deleting it.
Later I need to restore the machine temporarily, perhaps make some changes and archive it again..
First I need to identify the correct "archive" backup somehow (verifying it doesn't belong to an existing machine, but rather the correct one that I "archived" and deleted previously)
It's likely the old vmid has been recycled and is now in use again, so the newly restored machine gets a different vmid now
I make the required changes, and then back up the new machine, but with the new vmid, presumably the backup chain is now broken. I also need to be sure that the backup retention policy isn't stupid and end up pruning the only copy. (actually, this makes me wonder now how long term backups are managed in the event a vmid is recycled, that could be another cause for confusion)
That already feels like enough bookkeeping to prevent me from adopting this type of "archive" arrangement, and so the easier/safer option is to just leave the VM where it is, not running and not benefitting from any kind of compression/deduplication (while also being needlessly included in any regular backup cycle)
Would there be merit in developing the concept of an archive/deepfreeze model as a supported first class feature?
That is not how you would restore the VM. The ID is only recycled if you restore the VM inside of a VM, if you just go to backups and restore a backup, you have to choose a new ID if the old is already used.
With PBS, you could would have better control over the VMs and could also protect single backups or add a description to it.
I would also leave the VM there and put it into a special pool (used as a folder analog) or tag it "archived". I would also recommend as @Zalaare said another datasource, which could be compressed (higher). This is perfectly usable with a special ZFS dataset with large zvolblocksize of e.g. 128K (or higher) and high compression zstd-19 if you like. This will then be REALLY slow on access, yet if "resurrected", you could move the VM disk back to the fast storage, do your changes and then move the VM disk back. In additional still PBS so that the backups of a not-cached VM will not generate new files like vzdump would.