Old Server Data Retention.

[jai64]

I have a question about Old Server Data Retention.

Example:
If I create a backup job of 5 servers. They are large...
Backups run with a retention period of 30 days.
One server is replaced with a completely new server.
The new server is added to the routine and the old server deleted from ESX.

Question:
Is there any way to delete the old server from the backup file to reclaim that space?

Would it require to start a new backup job with all the servers in it and delete the whole other file to clear out that old servers backups? If I delete the file I will lose 30days backup on my other servers. If I save it I may run out of space.

Should I be creating a single backup for each server? and Will that hinder my speeds due to the "block change tracking" process. I use templates and cloning so speed is good.

I ask this question because:
1) I move a lot of servers around and have many of them.
2) My servers are large and I have minimal space available for backups.

Thanks
~ joe

[Vitaliy S.]

Hello Joe,

Actually, if you remove any VM from your backup job, it will not be removed from the backup itself, so if you add new VM to the job, the backup will grow in size. Basically, you should either create a new backup job with new list of servers or use the old one, however be aware if you remove the backups from Veeam console (for ex. moved it to tape or any other storage), you will be able to import your backups (VBK+30 rollbacks) later in order to do a restore.

On the other hand, if you use single job for a single server (VM), the de-duplication ratio will be less efficient, as it works only within the job. Obviously, backing up VMs from one template in one job will save you much more space rather than one-to-one configuration. As for "change block tracking" it doesn't depend on the amount of VMs added to the job.

Thank you

[jai64]

Thank You.

~ joe

[Gostev]

There is no need to re-create job to clean up VBK from removed VMs. You can simply perform full backup on the existing job (right-click the job, and you will see this option). The newly created VBK will only have VMs which are included in the job right now. The "previous" VBK will remain for a while, but will eventually go away after your chosen retention period passes.

[tsightler]

Do systems that are removed from a backup job ever age out of the VBK, thus releasing their blocks to be reused?

[Gostev]

No, nothing "ages out" from VBK. Only unused blocks are removed automatically - as soon as some block does not belong to any VM (dedupe pointer count becomes zero), it is removed from VBK. But actual VMs are not removed until you initiate full backup (which again does not "remove" VMs, but rather creates "new" VBK without those VMs present).

Main reason is that if we would age out VMs, then the backups of removed VMs would be completely lost after some time. Not a problem if you copy VBK to tape occasionally (you always have old VBKs available), but if you only backup to disk and do not make VBK copies from time to time like some smaller customers do - this will be an issue.

[tsightler]

Main reason is that if we would age out VMs, then the backups of removed VMs would be completely lost after some time. Not a problem if you copy VBK to tape occasionally (you always have old VBKs available), but if you only backup to disk and do not make VBK copies from time to time like some smaller customers do - this will be an issue.

This logic seems strange to me. If I have a retention policy that keeps 15 days on disk, and I remove a VM, I'd expect it to disappear if 15 days, not hang around for all eternity. This has a significant negative impact on larger customers as, the more VM's, the more change in the environment. Each time a VM is removed I have to re-run a full on the 2TB job, and then keep the old extra VBK around for weeks. Or I can make smaller jobs, but loose much the advantages of de-dupe. This is also an issue for restored VM's. We have jobs were the VM was restored, but now it's original will hang around forever. Very annoying and confusing. My only solution is to run a full of 2+TB of VM's.

As a suggestion, you could of course have an option, but perhaps an even better tool would be a "purge" function, or even an "archive" function. The "purge" function would allow you to remove a specific machine from a backup job (vbk), effectively freeing it's blocks for re-use. The "archive" function would allow you to extract an existing VM from a job (vbk) into a separate (vbk) containing only that VM, and freeing the space in the old vbk file. Don't know how practical, but I think the current situation is not good for larger customers.

[Gostev]

Good ideas!

[chad5k1]

This logic seems strange to me. If I have a retention policy that keeps 15 days on disk, and I remove a VM, I'd expect it to disappear if 15 days, not hang around for all eternity. This has a significant negative impact on larger customers as, the more VM's, the more change in the environment. Each time a VM is removed I have to re-run a full on the 2TB job, and then keep the old extra VBK around for weeks. Or I can make smaller jobs, but loose much the advantages of de-dupe. This is also an issue for restored VM's. We have jobs were the VM was restored, but now it's original will hang around forever. Very annoying and confusing. My only solution is to run a full of 2+TB of VM's.

As a suggestion, you could of course have an option, but perhaps an even better tool would be a "purge" function, or even an "archive" function. The "purge" function would allow you to remove a specific machine from a backup job (vbk), effectively freeing it's blocks for re-use. The "archive" function would allow you to extract an existing VM from a job (vbk) into a separate (vbk) containing only that VM, and freeing the space in the old vbk file. Don't know how practical, but I think the current situation is not good for larger customers.

Good idea. I'd like to see this added in future releases.

[stephaneb]

Hello,

I concur with the "purge" job idea.
This feature is definitely missing from the product.

Why can't we simply right-click a VM in the backups view and select "delete"?

As a matter of fact, being able to specify the backup retention in days (in addition to the number of version) would be extremely convenient.

Stephane

[Gostev]

We are implemeting VM level retention in v5. Removed VMs data blocks will now be freed for reuse automatically after specified data retention period. Thanks!

[fredbloggs]

Are you going to add the purge or export options.

Think export would be very useful, see I knew there'd be something else i'd forgotten as then when a VM is to be removed we can simply export that VM from the vbk and supply the end-user that backup file.

[Gostev]

Purge will likely be automated only, based on job's retention. No specialized export will be available in this release, but you can always export any VM from a backup file by restoring all VM files locally or to the selected storage - even today.