when backing up VMs with file level backup (aka "ALLVMFS") (and CBT, but doesn't matter here),
always a full backup is performed, even 'incremental' or 'level x' is scheduled, if the client attribute 'backup renamed directories' is set.
The level itself is recorded correctly in the meta data, but the amount of data backed up is always 'full'.
Is this a bug or a feature?
I haven't found any documentation about this behaviour with VADP. (´But there is an old note about VCB).
Only the following statement in the 8.1 Admin Guide:
Renamed directories and incremental backups
If the name of a directory is changed after a full backup, but no files or subfolders in the directory were changed, the renamed directory is not included in subsequent incremental backups.
To avoid this issue, select the Backup renamed directories attribute on the Client resource.
So, what will be the best way to go:
- enabling the attribute, backing up much to much data but very SAVE
- disabling the attribute, having real incrementals but at some RISK
Any more insight / hints / etc. welcome.
How often folders get renamed? If often data is renamed (why oh why), then you can use it for those specific machines.
Nice to see you here again 😉
Customer itself is large (internal) service provider and has no information about any changes in the VMs,
he only provides infrastructure (ESXi server, network, storage, etc.)
the service the customer provides is called "save(d)/secure(d) storage", so backup is included in the service
and putting data at risk is not an option - but backing up VMs still a requirement / desire.
Usually renaming of existing folders is manual action so I would expect they use some sort of solution which does not use that. Based on that assumption, I would not use option to backup renamed folders. If change ration would exist (can be easily seen based on volume of incremental backups), I would rather use full backup on daily basis for such machine.
Customer can not tolerate to lose data.
Customer can not afford to backup ALL VMs full every day (backup time, tape resouces, etc.)
Customer can not distinguish between VMs containing renamed directories or not.
Solution should be some kind of:
- incremental VADP backups for VMs possible without putting some data at risk
Will this eventually change with Backup Appliance (aka Avamar Engine - V8.1) deployed instead of using VADP?
OK, let's take step back. Are you sure that setting about renamed directories applies to VM backups? For example, if you use CBT you get list of changes blocks (which includes changed data) and this is backed up in return. If you want to save everything, then save everything - simple as that. I would suggest you test this scenario; simply have a idle VM and rename directory and see if next incremental will pick it up. Then test it with option enabled. If it turns out that it works with that option, then keep it on.
Sorry. At the moment, we are moving in a circle a bit.
We can easily show, that "backup renamed directories" leads to full backups (capacity wise) every time
using VADP and "ALLVMFS", regardless which level is scheduled.
Disabling "backup renamed directories" (removing the checkmark for this client) switches backup to true incrementals (CBT is enabled for the VMs in vSphere and used in NSR).
Enabling "backup renamed directories" again forces a full backup (capacity wise).
VM is 15GB in Size. FileLevel Backup with saveset "ALLVMFS" and "VADP_DISABLE_CBT = NO" is set.
Full is always 15GB in size.
Incrementals with "backup renamed directories" disabled vary between 800KB and 1500KB daily.
Instantly after turning "backup renamed directories" on, incrementals are always 15GB.
There are several hundreds VMs to backup.
At the customer site, there is NO way to distinguish between VMs containing renamed directories or not.
The key question here is: when you disabled option mentioned and within VM you do rename folder, does this get backed up due to CBT usage? Bare in mind that using renamed directories thingy was introduced not for VM snapshots, but rather backups with agents in legacy mode (so I would even argue that behavior you see is most likely not correct).
>> (so I would even argue that behavior you see is most likely not correct).
Of course, that argument should be addressed via support ticket - forum is more community thingy