VDR 1.1: How to limit maximum size for a cifs destination?

[frankLT]

Hello all,

we use VDR 1.1 to back up VMs to a cifs share. The amount of data on the destination volume grows quickly. Obviously VDR is unable to shrink the destination store as restore points are deleted. Although I deleted lots of old restore points, the destination folder is still growing in size as new backups are taken.

We want to prevent that all space on the destination volume will be used up by VDR. I already tried setting up a quota on the destination folder (W2K3 R2 feature), but VDR still shows the total volume space in its GUI, so I think that won't help.

Has anyone an idea how to limit space usage on a cifs destination?

Thanx and regards,

Frank

[ben13]

Hello Frank,

What about using a more restrictive retention policy (few or custom with less retention)? That should keep it much smaller. Its not exactly what you are looking for but should do the same thing.

Alternatively what about creating a new partition (or volume, not sure of your CIFS source) that is the max size you want and then use it? I still think the retention policy is the best way to go. Set it to custom and keep less backups.

Also keep in mind the initial full backups will be approx the size of all the VM data you are backing up (there is compression I beleive but to be safe don't count on it). Ex if you are backing up 5 Vms that are 10Gb each you'll need roughly 50Gb to start plus about 2Gb for the VDR files. Depending on how much changes on these systems the delta's shouldn't be that large but still will cause the destination to grow. EDIT forgot to mention it does dedupe so if yoru machines are similar, say all Win2k3 R2 that should cause it to be much smaller than the ex. 50Gb.

Hope that makes sense.

Ben

[frankLT]

Hi Ben,

thank you very much for your reply. I think that a more restrictive retention policy probably won't solve our problem. Even after old backups were deleted, the dedup store has kept its former size. And with every new backup, it's further increasing. Seems that the retention policy can slow down growth, but cannot prevent from filling up the destination volume after a certain period of time.

Perhaps we will really need a separate partition on the file store exclusively for vdr backups. Mmmmhh... not too flexible if we might have to extend it one day, but possibly the best solution. I already thougt about backing up to a vmdk, but we want to regularly backup the store content to tape. And a vmdk is always held open by the appliance vm, so that may be more difficult...

Any additional ideas will be appreciated.

Thank you,

Frank

[ben13]

Hey Frank,

I'm not sure why the destination is growing though, unless your machines are one that the data is constantly changing/growing? Otherwise it should only write delta's and then delete old delta's as per the retention policy. My destination typically hasn't changed much (grown) in the last month since I started using VDR. What is the total size of the VMs you are backing up and what is the size you'd like to keep the VDR destination? Maybe its not doable in your setup?

Ben

[frankLT]

Hi Ben,

the total size of backed up data is no problem so far. Deduplication does a great job, the total backup size is smaller than all the vmdks taken together. That's okay. I just wonder about the behaviour of vdr as it appends new backups to the existing storage rather than re-using space after removing restore points. I already removed some rather big VMs from the destination (and vdr reports them as successfully removed), but newly backed up data is still appended. Will the freed up space ever be used again?

We won't get into trouble immediately since there is plenty of free space, but I'm still trying to understand how vdr works, to find out if it's a suitable solution for us. If the destination volume fills up to its upper limit, I may have to create a dedicated volume where that won't matter.

I think we will simply have to observe the data growth for some time.

Ben, Thank you for telling me that your destination is not growing much. I'm drawing hope from that.

Frank

[ben13]

Hello again,

Thats good the store is still okay for you but I'm concerned that its not reusing space. Are you sure that is the case though? Wondering how you are verfiying that? From what I've observed our initial backup was around 350Gb then I have the policy set to the default "more" setting and it sits around 400Gb total. When the reclaim job runs it typically keeps in and around that same amount. Is your reclaim job running okay? Do you see it in the logs (the frequency I beleive is dependant on your retention policy).

To change the frequency of the job you'll need to create/edit the datarecovery.ini file, here are the official instructions. Maybe have it run the reclaim daily to ensure you have the free space you want? Not sure if that helps but worth knowing you can do it.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101317...

Not sure how comfy you are at a linux command line but if you need help just let me know.

Ben

[frankLT]

Hello Ben,

sorry for the delay. I tested and observed the system for some time now. I've adjusted our retention policy. Former settings included backups from the last 7 days plus the newest backups from last 4 weeks and 1 month. With our new settings only backups from the last 7 days are retained, NO older backups.

This leaded to a MUCH slower growth of the destination data size. It is still slightly growing with each new backup, but only some 100 MBs for currently 7 VMs which are backed up. So obviously keeping a single old restore point results in a significantly larger amount of data on the destination volume. Quite interesting.

Thank you for the link concerning datarecovery.ini. I could't get it working so far. Default Retention Policy Interval is 7 days, so I created a simple datarecovery.ini to reduce it to 1 day:

RetentionPolicyInterval=1

...but it is completely ignored. Already restarted the service, also tried rebooting the machine. I will have to examine why. I just mentioned that the article has been revised on January 5. The example has been removed. Perhaps someting changed with version 1.1 No more hint to start the file with an header. I will try to remove it and test again.

Bye,

Frank