Availability for the Always-On Enterprise
Post Reply
foggy
Veeam Software
Posts: 16691
Liked: 1343 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Large Incremental size

Post by foggy » Feb 07, 2012 4:07 pm

High fragmentation results in large sizes of incremental backups. Right, you can schedule it just before the full run.

Regarding the transferred data count, this could be a UI bug. I've passed the information to our QC team. Thanks.

Daveyd
Expert
Posts: 276
Liked: 11 times
Joined: May 20, 2010 4:17 pm
Full Name: Dave DeLollis
Contact:

Re: Large Incremental size

Post by Daveyd » Feb 07, 2012 5:46 pm

Thanks for the reply. It looks like the MYSQL DB server I mentioned above is 90% fragmented. Its going to take a considerable amount of time to defrag. I'm interested in seeing what type of reduction in incrementals I get when it finally completes.

Thanks for the bug check. It would be real nice to see the actual amount of data per VM that was tansferred to the repositiory in Enterprise Manger like the email report shows

Vitaliy S.
Veeam Software
Posts: 21395
Liked: 1273 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Large VIB file on a small static server

Post by Vitaliy S. » Feb 07, 2012 8:49 pm

foggy wrote:I would recommend that you try to defragment your VM disks plus running sdelete on them and see whether this helps.
This one is good for thick disks only, I wouldn't recommend running sdelete for thin disks without taking these steps afterwards.

Daveyd
Expert
Posts: 276
Liked: 11 times
Joined: May 20, 2010 4:17 pm
Full Name: Dave DeLollis
Contact:

Re: Large VIB file on a small static server

Post by Daveyd » Feb 07, 2012 9:27 pm

Gostev wrote:Hint, you can disable last access time updates to prevent this from happening.
Can that be done via the AV software or does it have to be done on an OS level/registry fix?

Daveyd
Expert
Posts: 276
Liked: 11 times
Joined: May 20, 2010 4:17 pm
Full Name: Dave DeLollis
Contact:

Re: Large VIB file on a small static server

Post by Daveyd » Feb 07, 2012 9:28 pm

Vitaliy S. wrote: This one is good for thick disks only, I wouldn't recommend running sdelete for thin disks without taking these steps afterwards.
In my case, I only have thick disks, no thin provisioned

foggy
Veeam Software
Posts: 16691
Liked: 1343 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Large VIB file on a small static server

Post by foggy » Feb 08, 2012 9:43 am

Daveyd wrote: Can that be done via the AV software or does it have to be done on an OS level/registry fix?
I doubt whether I've seen such settings in any of the AV products... Must be something like this.

Daveyd
Expert
Posts: 276
Liked: 11 times
Joined: May 20, 2010 4:17 pm
Full Name: Dave DeLollis
Contact:

Re: Large VIB file on a small static server

Post by Daveyd » Feb 10, 2012 2:10 pm

Well, I have a MYSQL VM that I defragged 2 days ago. Here are my results:

Before defrag:
C: 40GB - 11% fragmented
D: 60GB - 83% fragmented
Average daily growth of both drives: 250MB
Veeam Incremental vib: 4.9GB

After defrag:
C: 40 GB - 2% fragmented
D: 60GB - 2% fragmented
Average dail growth of both drives: 260MB
Veeam Incremental - 5.0GB

Obviously the initial incremental after the defrag was HUGE but the subsequent vib was the same size before the defrag. I have not run sdelete on the VM but with such a small change rate and a defrag, I'm surprised that the vibs didn't shrink

Vitaliy S.
Veeam Software
Posts: 21395
Liked: 1273 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Large VIB file on a small static server

Post by Vitaliy S. » Feb 10, 2012 4:13 pm

Dave,

Unfortunately, I didn't notice that you're backing up a MySQL VM, my bad.

Actually this is perfectly normal for servers with high rate of disk changes (Exchange, SQL, Oracle).

Be aware that for every changed block in MySQL VM Veeam will pick up a 512 KB data block (LAN target), so to reduce incremental file size I would recommend switching to WAN target instead. In this case Veeam B&R will use smaller data blocks (256 KB), which will result in the maximum deduplication ratio and the smallest size of backup files.

Please note that changing this setting on existing job only takes effect after full backup is done.

Thanks!

Daveyd
Expert
Posts: 276
Liked: 11 times
Joined: May 20, 2010 4:17 pm
Full Name: Dave DeLollis
Contact:

Re: Large VIB file on a small static server

Post by Daveyd » Feb 10, 2012 6:33 pm

Thank you for the info Vitaliy. My backup target is an Exagrid appliance. Will changing the job to WAN target have any adverse affects on deduplication on the Exagrid appliance...Exagrid recommends using LAN target

Vitaliy S.
Veeam Software
Posts: 21395
Liked: 1273 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Large VIB file on a small static server

Post by Vitaliy S. » Feb 10, 2012 7:15 pm

Deduplication ratio might be lower on Exagrid, on the other hand you will have much smaller VIB files.

The best way to figure out what's better for you is to test it yourself. :wink: I would appreciate if you could post back your results so we could compare.

tsightler
Veeam Software
Posts: 5167
Liked: 2057 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Large VIB file on a small static server

Post by tsightler » Feb 10, 2012 9:34 pm

Also, you can't really compare growth rate to VIB size. Growth rate of disk space only accounts for new data added, but with a SQL server, and really with any server, there are likely to be significant changes to existing data.

Daveyd
Expert
Posts: 276
Liked: 11 times
Joined: May 20, 2010 4:17 pm
Full Name: Dave DeLollis
Contact:

Re: Large VIB file on a small static server

Post by Daveyd » Feb 13, 2012 5:23 pm

Vitaliy S. wrote:Deduplication ratio might be lower on Exagrid, on the other hand you will have much smaller VIB files.

The best way to figure out what's better for you is to test it yourself. :wink: I would appreciate if you could post back your results so we could compare.

Well, I changed the Dedupe process from "Local target" to "LAN target" and also did a defrag. Here are my results thusfar,

VM prior to Veeam settings change and defrag:

C: 40GB - 9% fragmented
D: 120GB - 74% fragmented
Veeam incremental data backed up - 21.1GB

After Veaam settings change to "LAN target" and a full defrag:

C: 40GB - 2% fragmented
D: 120GB - 2% fragmented
Veeam incremental data backed up - 5GB

The new 5GB incremental size is on a weekend incremental where the DB does still get hit but not as hard as during the week. I will be interested to see how much incremental data gets backed up tonight.

Daveyd
Expert
Posts: 276
Liked: 11 times
Joined: May 20, 2010 4:17 pm
Full Name: Dave DeLollis
Contact:

Re: Large Incremental size

Post by Daveyd » Feb 13, 2012 5:25 pm

foggy wrote:Regarding the transferred data count, this could be a UI bug. I've passed the information to our QC team. Thanks.
Any update on this?

foggy
Veeam Software
Posts: 16691
Liked: 1343 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: Large Incremental size

Post by foggy » Feb 14, 2012 12:43 pm

Daveyd wrote: Any update on this?
This is confirmed as a bug and will be addressed in one of the future product updates.

Unison
Enthusiast
Posts: 85
Liked: 16 times
Joined: Feb 17, 2012 6:02 am
Full Name: Gav
Contact:

[MERGED] Unusually Large Increments from Veeam???

Post by Unison » Mar 09, 2012 5:36 am

Hi guys,
Im having a bit of an issue here with Veeam compared to my old imaging software (symantec System Recovery). The full backups of my servers are smaller with veeam (which is great) compared to the old backup solution however each increment that is done with veeam is much bigger than the increments done with the old backup product - im at a loss as to why this is and its blowing out our archive storage and creating issues for tape backup.
For example, some of our 'quieter' servers used to have increments of around 300-500MB....now with veeam, the increments on those same servers are around 4-8GIG! - each time! This adds up real quick.

I suspect that the reason for the huge increments is the OS page file - veeam keeps backing it up with each increment because it changes frequently. Am i wrong or could there be another cause for these large increments?
I read that version 6 of veeam (which i am running - with esxi5 - backing up Server03 VMs) has the ability to 'ignore' or exclude page/swap files from the backup process - GREAT!!! I have checked the settings on all my jobs and this setting is ticked - but it doesnt seem to be working here.

Has anyone else had issues with extremely large increments? been able to work out what is causing the large increments?
I would prefer to not create a new vmdk just for the paging file if possible - and seems like v6 really makes this unnecessary now - is there anything anyone can think of that might be causing these large increments on a server that does not change very much at all daily.

Info:
-CBT is enabled
-Increments are done daily
-Pagefiles are on the C partition of OS
-No synthetic fulls or reverse incrementals in use - all are base weekly with incrementals through the week.

Thanks guys,
Appreciate any help you can offer :)

Post Reply

Who is online

Users browsing this forum: No registered users and 20 guests