vzdump feature request

[tog]

I have a simple feature request for vzdump. Since it has evolved into more of a full backup script and not just a command to be integrated into a custom backup script...

The only thing it doesn't do for for me that my backup script used to is multiple rotated backups for safety's sake.

When I begin my backup I simply "mv vzdump-101.tgz vzdump-101.tgz.0" and then begin my new dump to vzdump-101.tgz. That way in case something happens in the middle of a backup I still have my old one.

 

[Erwin123]

Hi Tog, that would be a great feature.
But since I move the backups from my server anyway I use Rsnapshot. If you don't know it yet, you should take a look at it.

 

[tom]

I have a simple feature request for vzdump. Since it has evolved into more of a full backup script and not just a command to be integrated into a custom backup script...

The only thing it doesn't do for for me that my backup script used to is multiple rotated backups for safety's sake.

When I begin my backup I simply "mv vzdump-101.tgz vzdump-101.tgz.0" and then begin my new dump to vzdump-101.tgz. That way in case something happens in the middle of a backup I still have my old one.

the suggested way is to make the backup via vzdump to a remote location. e.g. we mount a samba share as a backup target on Proxmox VE.

the samba share is on our backup server where a daily backup is done to tape. so we have the data off line on a tape, every day.

 

[tog]

the suggested way is to make the backup via vzdump to a remote location. e.g. we mount a samba share as a backup target on Proxmox VE.

the samba share is on our backup server where a daily backup is done to tape. so we have the data off line on a tape, every day.

The way I do things I still need to do this rotation step to keep the old backup from last night or I run the risk of not having a backup at all. I don't use tapes, just rsync, so even if I dump direct to another server via NFS or SMB, the following could still happen to me during my backup process:
1) Vzdump for CT101 starts, the vzdump-101.tgz file is removed at the start of the backup and the backup begins streaming to vzdump-101.dat.
2) Proxmox VE server dies in the middle of the CT101 vzdump, total HDD failure.
3) A bit later the nightly rsync from local backup server to other backup server goes ahead and syncs the backup directory as-is with the half-finished vzdump-101.dat and no vzdump-101.tgz.
4) I have no vzdump-101.tgz to restore from.

Regardless of where the vzdump output files are placed, it would still be nice to have a basic rotation function, otherwise vzdump falls one minor feature short of being a complete backup script for me. Move the last night's vzdump out of the way before starting on tonight's rather than simply rm'ing it. The command line option could be simple "--rotate 1" to indicate you wanted to keep one vzdump backup rotated.

If vzdump did that for me, I'd be done, no additional scripting necessary. I could just use backup from web interface, the way the web interface set it up would be all I'd need, total dummy mode. Without a rotation feature I still need to throw in some custom scripting.

Rsnapshot is nice, but I just use plain rsync to update my backups from one place to another. I use rsnapshot elsewhere for backups but it's not really the right tool just for dealing with these vzdumps. Rsnapshot uses hardlinks to conserve space so it only has to store files that have changed. Unfortunately that doesn't help when I'm just working on a directory full of large stuff that changes out every file every night. There's no real benefit to using rsnapshot as opposed to very simply scripting "mv vzdump-101.tgz vzdump-101.tgz.0" at the start of the backup process.

 

[dietmar]

The command line option could be simple "--rotate 1" to indicate you wanted to keep one vzdump backup rotated.

Added this to our todo list.

- Dietmar

 

[tom]

The way I do things I still need to do this rotation step to keep the old backup from last night or I run the risk of not having a backup at all. I don't use tapes, just rsync, so even if I dump direct to another server via NFS or SMB, the following could still happen to me during my backup process:
1) Vzdump for CT101 starts, the vzdump-101.tgz file is removed at the start of the backup and the backup begins streaming to vzdump-101.dat.
2) Proxmox VE server dies in the middle of the CT101 vzdump, total HDD failure.
3) A bit later the nightly rsync from local backup server to other backup server goes ahead and syncs the backup directory as-is with the half-finished vzdump-101.dat and no vzdump-101.tgz.
4) I have no vzdump-101.tgz to restore from.

Regardless of where the vzdump output files are placed, it would still be nice to have a basic rotation function, otherwise vzdump falls one minor feature short of being a complete backup script for me. Move the last night's vzdump out of the way before starting on tonight's rather than simply rm'ing it. The command line option could be simple "--rotate 1" to indicate you wanted to keep one vzdump backup rotated.

If vzdump did that for me, I'd be done, no additional scripting necessary. I could just use backup from web interface, the way the web interface set it up would be all I'd need, total dummy mode. Without a rotation feature I still need to throw in some custom scripting.

Rsnapshot is nice, but I just use plain rsync to update my backups from one place to another. I use rsnapshot elsewhere for backups but it's not really the right tool just for dealing with these vzdumps. Rsnapshot uses hardlinks to conserve space so it only has to store files that have changed. Unfortunately that doesn't help when I'm just working on a directory full of large stuff that changes out every file every night. There's no real benefit to using rsnapshot as opposed to very simply scripting "mv vzdump-101.tgz vzdump-101.tgz.0" at the start of the backup process.

Just a short story for you:

I know a hosting provider who did "backups" via rsync to a second server. He tells all the customers that he is doing daily full backups.

But then the primary server got hacked and due to online connection to the backup server also all files from the "backup" servers where deleted.

So he had to explain to hundred of customers that ALL data is lost and no backup is available.

So take care if you do not store backups offline on tapes.

 

[tog]

It's a good word of caution.

If the server itself were compromised and then the rsync password was used to delete the vzdump backups from the first backup server I still have daily, weekly and bi-monthly ZFS snapshots on the local and the offsite backup servers to pull vzdump*.tgz out of.

Both backup servers could be compromised and vandalized at the same time, or a tape backup could fail to restore...