Tape Backup - Achive Bit

[2Tall]

Hi to all. I am new to Veeam and am using version 5. I still have a requirement to backup to tape (daily / weekly). I have 2 Veeam Backup Jobs. Both Veeam jobs are scheduled for incrementals Mon-Sat then a Full on Sunday (retention 14 days). The target is a HP StorageWorks D2D2504i - G2.

I have 2 jobs configured in Symantec Backup Exec 2010 R3 (Veeam Daily that backs up .vib and Veeam Weekly that backs up .vbk). I have chosen Symantec Include/Exclude Option 'Only Modified Files'.

I note that the .vib and .vbk files on the D2D box have the Archive Bit set. Symantec therefore backs up all files and does not reset the Archive Bit. This gives me a a headache as I do not have capacity on tape to backup all .vbk files in my weekly backup to tape.

Veeam support advised me to try the forums so here I am

I would appreciate any input on how I can continue with tape backups as required. If you require any further information I am happy to provide it.
Kind Regards,
Phil.

[Sethbartlett]

Instead of going off of archive bit, why not have a script that grabs the latest VIB or latest full(depending on the day)?

[Vitaliy S.]

Hi Philip,

I do not have enough expertise in using BE, but I'm pretty sure there should be an option to use file masks to filter and offload only *.vib or *vbk files to tapes. Can you check that?

Besides, here is an existing topic, that would allow you to pick up the latest file created and move it to tapes.

Thanks.

[2Tall]

Hi. I have filtered BE to select either *.vib or *.vbk files however I only want the latest. I will take a look at the link to the other topic as a script would seem a good way to go.
Thanks,
Phil.

[habibalby]

Hello,

Did you solve your issue? I'm in the same situation but only the difference with me is I'm Replicating my VMs to DR and I initiate the Backup at the DR Site as Reversed Incremental. This leaves me only with one .VBK file, I O.K with this because I'm lacking out of disk space at the DR Site.

I have applied the DisplayVBKRename to avoid reconfiguring backup JOBs in Symantec.

In Symantec, I have configured two JOBs one is full backup that runs only on Friday and another job as Incremental that runs daily. I have noticed that, the Incremental job it doesn't backup files as incremental and it always full backup which put me in a dilemma.

On a test VM in Production, I have put 8 GB file and I replicated it. The 8 GB files replicated to the DR and I can see them at the DR Site. But when I run the Backup Job in Symantec, it always maintain the same .VBK File size. But when I right click the job Veeam Job and select Perform Full Backup, it renames the .VBK File and it increase the .VBK File.

Any help to this Dilemma?

Thanks,

[Vitaliy S.]

I'm in the same situation but only the difference with me is I'm Replicating my VMs to DR and I initiate the Backup at the DR Site as Reversed Incremental.

Are you trying to backup replicated VMs? Have you disabled CBT for the backup job, as it is not possible to use CBT to backup replicas.

But when I right click the job Veeam Job and select Perform Full Backup, it renames the .VBK File and it increase the .VBK File.

Seems like you haven't applied the key properly, as VBK file shouldn't be renamed.

[habibalby]

Hello,
Not I haven't uncheck the CBT and I do run a Backup while the VM is powered Off.

The registry Key applied successfully, because it didn't change the vbk file name unless I click on Perform Full Backup.

Thanks,
S.Hussain

[Vitaliy S.]

CBT have to be switched off, as replicated VMs have incorrect CBT ID or even do not have it updated (don't remember). I guess this is the main reason for your issue with VBK file.

[habibalby]

Fine, let me disable the CBT and get back to you.

Thanks for the prompt reply.

[habibalby]

Disabling the CBT, backup takes hell of time imaging 3 TB of VMs I'm backing up how hell is that?

[Vitaliy S.]

Yes, your backup job will take the same time as a full run. Based on your previous posts, you're still running on Veeam B&R v5, right?

Reading through both posts (in this thread and the one I've just referenced), CBT have to be disabled, which means that we'll be using our legacy changed block tracking mechanism for incremental backup. This pass will take the same amount of time as a full run.

[habibalby]

Hi, Yes I'm on version 5. Hummmm, there is not way to come around this? Imaging VMs with 1 TB, 800GB or 670GB of VMDKs?

[Vitaliy S.]

The only workaround I know is to backup your production VM directly.

[habibalby]

Maybe going with Normal Incremental instead of Reversed Incremental will sort out the issue with Symantec Archive Bits as this option will give me VBK which is full and VIB file which is the incremental. May be, I have to try it out.

[Vitaliy S.]

I'm afraid my answer will be again - no. It doesn't matter what backup mode you choose, CBT simply cannot be used while backing up replica VM in your case.

[habibalby]

Thank you

[zoltank]

[merged]

We have a tape library which we use to create tapes for our offsite DR backup. Since our jobs are reverse incrementals we only need to back up the .VBK file since we're only interesting is restoring the latest backup of a VM.

However, the problem is the file name of the .VBK file changes every time the job is run, and the file access date for the .VBK stays at the date the .VBK file was created. Therefore, right now I'm stuck manually selecting the correct .VBK files every time we backup to tape. Obviously I want to automate this process, and am trying to find ideas on how to do so.

[chadtandy]

Set the tape job to run a full backup on that directory and set a filter to exclude non .VBK files.

-Chad

[zoltank]

After struggling with this for a day I figured out how to do it right after creating this thread. Figures.

The problem I had with just backing up the .VBK files is I regularly perform Full Active backups to refresh the backup data. Therefore, there are usually two or three .VBK files in the repository for any one backup job, and I obviously don't need to want to back up those older .VBK files. I should have mentioned this in my original post.

The solution I found was to clear the archive bit on all files in the repository, and then have my backup software (Backup Exec 12.5) do an incremental backup of the repository since Veeam resets the archive bit on the latest .VBK file every time the job runs.