Hi,
I have multiple customers at with I user Veeam to backup their VM's.
I normaly configure the backup server as a HP DL380 (dual quadcore, 8+ GB RAM, W2K8R2) with an MSA 60 (with 6 to 12 1TB SATA disks) and an autoloader or other tape device.
I configure Veeam with multiple backup jobs to run concurrent backups (backup window is more important than maximum dedup ratio) and set the job to maintain 5 rollback points and a full backup to run each friday.
I use BackupExec to transfer the Veeam directory to tape (Please add tape support to transfer the Veeam backup location to tape in a future release!!!)
It seems everything works just fine, except for some strange thing that if I configure the backup server on, lets say wednesday, the first backup is a full. So lets say about 300GB is created on disk. The next day (thursday) is an incremental and another 50GB are added as incremental files to the backup. Now the following backup is a full, and know things go wrong. Another 300GB is addes to the disk. Monday another incremental adds 45GB, thuesday the incremental adds 45GB, wednesday again an incremental adds 45GB, but the original 400GB file remains in place even after 5 weeks of backup. This isn;t a very big issue when my customer is using a autoloader, but it is when they use a dedicated tape drive like a LTO4 drive. I can nearly fit 830GB of Veeam data on a single tape and with the example above my calculation is 300GB + 4 (number of rollback points-1) x (15% (average percentage amount of changed data) of 300GB) = 480GB. In this case a LTO4 drive is sufficient and allows for some growth. But know the situation is 300GB + 300GB + (4 x 45GB) = 780GB and this eliminates almost all space for growth and with 350GB or more space of initial data it simply doesn't fit a single tape drive and my advise proved wrong and so this becomes an expensive issue for me.
I figured out a way to work arround this problem. The only way to solve this is to manually remove all Veeam backup data on friday afternoon so the friday full will be the only full.
Is this normal behavior or simply a bug that gets fixed in V5 of in a patch update for V4?
-
- Novice
- Posts: 9
- Liked: 3 times
- Joined: Oct 20, 2010 8:47 am
- Full Name: Jeroen Leeflang
- Contact:
-
- Chief Product Officer
- Posts: 31796
- Liked: 7297 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Full backup disk file not overwritten
Hello! Original full should not remain for 5 weeks with 5 days retention policy... it should be killed in 5 days... please contact our support so that they could research this more closely, and understand why the backup file is not getting removed according to the retention policy. I have not seen this reported before... Thanks!
-
- Novice
- Posts: 9
- Liked: 3 times
- Joined: Oct 20, 2010 8:47 am
- Full Name: Jeroen Leeflang
- Contact:
Re: Full backup disk file not overwritten
Ok.
I will try to reproduce the problem, because I used the work arround at my customers, and report the results to the support department.
I will try to reproduce the problem, because I used the work arround at my customers, and report the results to the support department.
Who is online
Users browsing this forum: aleksey.bashkirtsev, Bing [Bot] and 55 guests