Backup / Tape setup??

[lordjeffers]

Hi All,

I'm a newbie when it comes to Veeam. I have Veeam nicely doing what BackupExec couldn't do in my vSphere 5.1 environment and that is to reliably back up my VMs. Awesome.

What I would like to know is how to configure my jobs to backup to tape (Quantum i80 library with four fiber-channel LTO5 drives). Here is what I would like to have:

Daily incremental backup to NAS with weekly synthetic fulls - 30 restore points
Weekly backup of the full backups to tape with a retention of 26 weeks, with the tapes going off site

I can't find much documentation or guidelines and am hoping to get some pointers from you guys.


Thanks....

[veremin]

Hi, David.

If I were you, I’d, probably:

• Create a media pool with required retention period (overwrite data for 28 weeks)
• Create a backup to tape job
• In the settings of backup to tape job select the created media pool as a medial pool for full backups
• Deselect option “Process incremental backup”
• Set backup to tape job to run on the day when synthetic full is performed (at the time when it’s certainly finished)

Thanks.

[Dima P.]

Hello David,

I assume you successfully connected your tape device to Veeam B&R server, if not - please update this thread.

I can't find much documentation or guidelines and am hoping to get some pointers from you guys.

For the detailed step by step instructions - please use our beautiful User Guide Working With Tape Media part (p.423)

[lordjeffers]

Hi,

Yes Veeam is happily seeing the tape library, all of its slots and the four LTO 5 drives. I'll head on over to the beautiful guide and see how I get on...

Thanks

[veremin]

Kindly, keep us updated about the results you get. Thanks.

[lordjeffers]

Hi all,

Thanks for the helpful pointers. I think things are working well here, but here are some of my findings:

* Copy to tape can be really slow when reading from a deduped Windows Server 2012 volume. (set files not to dedup until 2 days old which helps massively)
* Job progress reports 99% when the job moves to a second tape (sometimes).
* I've had one media set take a tape that had been allocated to a different set and write to it
* One of my jobs kept saying that there were no files to write, even though there had been new files created
* Jobs failed due to issues accessing the database:

25/10/2013 07:22:30 :: Task E:\vBackups\App _ DB Backups\App _ DB Backups2013-10-13T030052.vib failed: Microsoft SQL server hosting the configuration database is currently unavailable. Possible reasons are heavy load, networking issue, server reboot, or hot backup.
Please wait, and try again later.

Error information:
Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.
The statement has been terminated.

Veeam Case for this one: 00466601

That's about it for now...

[veremin]

Hi, David.

Copy to tape can be really slow when reading from a deduped Windows Server 2012 volume. (set files not to dedup until 2 days old which helps massively)

I’d say, this is expected, since the deduplicated data needs to be re-hydrated first before being written to tapes. Thus, copying non-deduped data shows better performance rates.

Job progress reports 99% when the job moves to a second tape (sometimes)

Probably, GUI glitch or something similar. Does it result in further issues or it’s more about simple inconvenience?

I've had one media set take a tape that had been allocated to a different set and write to it

Might it be that there were no free tapes available at that time and the one that was allocated to different mediaset had already exceeded its retention period?

Jobs failed due to issues accessing the database:

As per description, it looks like overloaded SQL issue. So, the question is whether or not there was a high load put on the SQL server at that time and what edition of SQL server is being used (Full, Express)?

Thanks.

[lordjeffers]

Thanks for your comments.

Probably, GUI glitch or something similar. Does it result in further issues or it’s more about simple inconvenience?

Yes just a GUI glitch. The actual job progress reports an accurate percentage, but the percentage of the backup job inside jumps to 99%. Not a big issue at all.

Might it be that there were no free tapes available at that time and the one that was allocated to different mediaset had already exceeded its retention period?

The retention period of all media sets is set to 3 months. I'm pretty sure that there were tapes available in the free media pool. This is being investigated by Veeam Support.

As per description, it looks like overloaded SQL issue. So, the question is whether or not there was a high load put on the SQL server at that time and what edition of SQL server is being used (Full, Express)?

No issues with the SQL server. The job still failed after a reboot and with no other jobs in progress. This is on a physical, high-spec server.

[veremin]

Then, it seems that only deep log investigation is likely to shed a light on the root cause of the said issues. So, keep working with support team on investigating this problem.

Thanks.

[Tobias_Elfstrom]

Hello, did you ever found out what was the issue?

I have started to see the fail of some of my backup tape job at 99% with the "Subquery returned more than 1 value" error as well. And just as for you doesn't seem to be related to load at all.

I did noticed that there is a fix for the same error in "patch3" so I will apply that and see what that gives before filing a support case.

BR Tobias

[veremin]

This issue should have been fixed in the latest patch, indeed. So, please, update your product installation and post the results here. Thanks.

[Tobias_Elfstrom]

The patch3 did not help in my case.
Recreating the backup job with the same name did not help.

However I got a workaround working on two different installations of Veeam Backup & Recovery.
Changing Media Pool for the backup job makes it work.

[veremin]

Once you have a time, can you, please, open a ticket with our support team and provide them with required logs? They might be interested in it, as this issue should have been fixed in the latest patch. Thanks.

[Tobias_Elfstrom]

Sure, no problem. Case 00522789

[veremin]

Thanks for providing the ticket number. I've already asked QA team to take a look at your case.

[czinck]

Can you post the solution when you know? I'm having the same problem after installing Patch 3

Tks,
Chris Zinck

[veremin]

Hi, Chris,

I strongly encourage you to open your own ticket. Not will it help us to understand the root cause of this behavior better, but also it will allow you to solve your issue faster.

Thanks.

[Tobias_Elfstrom]

Can you post the solution when you know? I'm having the same problem after installing Patch 3

Tks,
Chris Zinck

Sure, no response yet other than request for more logs but as I said, for me it helped to change media pool for the jobs that fails. Not really tape efficient but still a workaround.

[Tobias_Elfstrom]

Got a more meaningful response today from "the developers" via support.

After the investigation of the log files and the database dumps, they have confirmed that the issue comes from earlier versions which had a bug that could lead to an incorrect marking of tape header data. They have also confirmed that it is not safe to try to change the sequence number in the database and in the tape headers, and the recommended way of fixing this is recreating media pools affected. This bug is fixed in the version you are currently running (the problematic tapes we have reviewed were incorrectly marked back in 2013).

So basically, in my case, the bug in earlier version screwed up the tape headers and the only safe way around this is to start using a new mediapool/mediaset. (And since that was my workaround already I will not dig into this any deeper.)

Br Tobias.

[Dima P.]

Tobias,
Thank you for posting heads up and a workaround to this thread - highly appreciated!