Large VIB file on a small static server

Availability for the Always-On Enterprise

Re: Large Incremental size

Veeam Logoby foggy » Tue 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.
foggy
Veeam Software
 
Posts: 15074
Liked: 1110 times
Joined: Mon Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson

Re: Large Incremental size

Veeam Logoby Daveyd » Tue 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
Daveyd
Expert
 
Posts: 272
Liked: 10 times
Joined: Thu May 20, 2010 4:17 pm
Full Name: Dave DeLollis

Re: Large VIB file on a small static server

Veeam Logoby Vitaliy S. » Tue 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.
Vitaliy S.
Veeam Software
 
Posts: 19767
Liked: 1120 times
Joined: Mon Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov

Re: Large VIB file on a small static server

Veeam Logoby Daveyd » Tue 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: 272
Liked: 10 times
Joined: Thu May 20, 2010 4:17 pm
Full Name: Dave DeLollis

Re: Large VIB file on a small static server

Veeam Logoby Daveyd » Tue Feb 07, 2012 9:28 pm

Vitaliy S. wrote:
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.


In my case, I only have thick disks, no thin provisioned
Daveyd
Expert
 
Posts: 272
Liked: 10 times
Joined: Thu May 20, 2010 4:17 pm
Full Name: Dave DeLollis

Re: Large VIB file on a small static server

Veeam Logoby foggy » Wed Feb 08, 2012 9:43 am

Daveyd wrote:
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?

I doubt whether I've seen such settings in any of the AV products... Must be something like this.
foggy
Veeam Software
 
Posts: 15074
Liked: 1110 times
Joined: Mon Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson

Re: Large VIB file on a small static server

Veeam Logoby Daveyd » Fri 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
Daveyd
Expert
 
Posts: 272
Liked: 10 times
Joined: Thu May 20, 2010 4:17 pm
Full Name: Dave DeLollis

Re: Large VIB file on a small static server

Veeam Logoby Vitaliy S. » Fri 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!
Vitaliy S.
Veeam Software
 
Posts: 19767
Liked: 1120 times
Joined: Mon Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov

Re: Large VIB file on a small static server

Veeam Logoby Daveyd » Fri 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
Daveyd
Expert
 
Posts: 272
Liked: 10 times
Joined: Thu May 20, 2010 4:17 pm
Full Name: Dave DeLollis

Re: Large VIB file on a small static server

Veeam Logoby Vitaliy S. » Fri 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.
Vitaliy S.
Veeam Software
 
Posts: 19767
Liked: 1120 times
Joined: Mon Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov

Re: Large VIB file on a small static server

Veeam Logoby tsightler » Fri 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.
tsightler
Veeam Software
 
Posts: 4830
Liked: 1779 times
Joined: Fri Jun 05, 2009 12:57 pm
Full Name: Tom Sightler

Re: Large VIB file on a small static server

Veeam Logoby Daveyd » Mon 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: 272
Liked: 10 times
Joined: Thu May 20, 2010 4:17 pm
Full Name: Dave DeLollis

Re: Large Incremental size

Veeam Logoby Daveyd » Mon 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?
Daveyd
Expert
 
Posts: 272
Liked: 10 times
Joined: Thu May 20, 2010 4:17 pm
Full Name: Dave DeLollis

Re: Large Incremental size

Veeam Logoby foggy » Tue Feb 14, 2012 12:43 pm

Daveyd wrote:
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?

This is confirmed as a bug and will be addressed in one of the future product updates.
foggy
Veeam Software
 
Posts: 15074
Liked: 1110 times
Joined: Mon Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson

[MERGED] Unusually Large Increments from Veeam???

Veeam Logoby Unison » Fri 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 :)
Unison
Enthusiast
 
Posts: 80
Liked: 16 times
Joined: Fri Feb 17, 2012 6:02 am
Full Name: Gav

PreviousNext

Return to Veeam Backup & Replication



Who is online

Users browsing this forum: Google Feedfetcher and 110 guests