Backup Directly to Tape

[EddyChong]

Hi,

I have a customer asking the question:
Does Veeam able to do D2T? (Directly backup VMs to tape library without needs to backup to disk)

I know Veeam does D2D2T. We can creates backup to tape job, we could selects either from backup job or from repository.
I am a bit confuse when talking about creating a backup to tape job from backup jobs. Does it means just linking? (after the d2d job finished then backup to tape job which linked will be started immediately and push the backup files which just being created to tape)

or does it means we create another set of backup files from VM directly (like the d2d backup job did) and then push directly to tape?

I doubt we can directly backup to tape. Can someone clarify this? It will be very much appreciated. I could not test it out since i don't have tape or mhvtl setup in my test lab.

Thank you
Eddy

[foggy]

I am a bit confuse when talking about creating a backup to tape job from backup jobs. Does it means just linking? (after the d2d job finished then backup to tape job which linked will be started immediately and push the backup files which just being created to tape)

Eddy, your understanding is correct. Veeam B&R does not perform backup directly to tape, you need to backup VMs to disk first and then copy backup files to tape using either backup to tape or file to tape job.

[EddyChong]

Hi Alexendar,

Thanks! This question was came from a customer with Symantec experience.

Eddy

[EddyChong]

Hi,

I got a follow up question. If we did the following:
1. Backup to disk and then push to VTL.
2. From VTL backup files is then push to physical tape library

When it comes to restoration scenario, backup files from physical tape library are restored to a disk location and then being imported to Veeam repository.
Does the recovery points chain still preserve? Personally i think Veeam will not recognize since the backup files were push to physical tape using Falconstor VTL.

Eddy

[veremin]

Does the recovery points chain still preserve?

Import via .vbm file allows you to import the whole backup chain. Thanks.

[EddyChong]

Hi Vladmir,

Noted. That means i need to have the whole set of full and incrementals with associated vbm (metadata) then i'm fine to import the backup files, am i correct?

Thank you
Eddy

[veremin]

Correct.

[EddyChong]

Thanks!

[foggy]

Actually you can import a chain even without the VBM file, just selecting the VBK. VBM allows for more robust import operation though.

[EddyChong]

Then let say if the set of files restored from physical disks were somehow without the vbm file, can I say the backup chain still preserved?

Since according to Veeam guide


I assumed it won't be mapped to existing backup jobs in this case.

Thanks
Eddy

[veremin]

Can I say the backup chain still preserved?

Yes, even without .vbm, the whole chain should be imported via .vbk file. Though, it never harms to have .vbm at hand. Thanks.

[EddyChong]

Noted with thanks!

Eddy

[veremin]

You're welcome. If any other questions arise, feel free to contact us. Thanks.

[cczornenki]

Hello, we are evaluating veeam to replace Symantec Backup Exec.

We can´t find the way to perfrom backups directly to our Dell Powevault TL 2000 . The non exclusive driver is working properly and the tape is correctly identified.

Is there anyway we can skip backup to disk ?

Best,
Christian

[foggy]

Hello, Christian. There's no way to skip backup to disk.

[larry]

How about using tape drives using the LTFS drivers, Veeam would think it is a disk. I want to test this but have not yet.

[veremin]

It might work. Though, as mentioned in the adjacent thread, you will have to perform all tape-related operations (change, eject, etc.) manually, which might be a time consuming process. Thanks.

[gdavid16]

is there a way to send a virtual machine directly to tape without hitting disk?
it seems that the options are backup to disk jobs and file/folders

[Dima P.]

Hi gdavid16,

Unfortunately, it’s not supported - Veeam B&R tape backup follows the disk to disk to tape approach.

[veremin]

Though, you still can create a local backup job, set a pretty short retention for it, and use the job as a source for backup to tape job afterwards. Not only will it allow you to have a virtual machine backup stored on tapes, but also it guarantee at least two copies of your backup data (recommended practice). Thanks.

[Dave338]

I have my backup jobs with 2 days retention (reverse incremental), like Eremin mentioned, and a backup copy job with 2 weeks daily plus one monthly backup retention, and my tape jobs reading data of my backup jobs.
I run active fulls every three months alternating my three backup jobs, so no excessive amount of data is stored more than two days.

After investing and testing various backup strategies, this one has been the winner and they're working without issues for many months

Regards.

[veremin]

Yep, David, your plan looks absolutely solid and is perfectly in-line with famous 3-2-1 rule.

[rreed]

Could we make this a feature request please? It would be handy for in a pinch situations where you don't have the time, inclination, HDD space, etc. and don't care how slowly it might run, etc.

[veremin]

Yes, you can. But keep in mind that we're cautious to implement functionality that is against the recommended best practices.

Anyway, even today you can archive files residing on a particular server directly to tapes, using files to tape job.

Thanks.

[rreed]

Many thanks for the feedback, and yes I agree B2D2T and 3-2-1 rule are best, but as mentioned sometimes we're in a pinch for time, don't have the disk space landing zone big enough to even temporarily hold a large VM, etc. It would be nice to have as an option, and as end users we accept the risks. For our shop it would only be the as-needed exception to the rule, rather than practice.

[rreed]

OH! Before I forget, direct to tape - AT SPEED - would be a necessity as well if that's possible please. I don't know if that expectation is realistic, because we found Backup Exec direct to tape speed was abysmal despite B2D2T being able to run great (remote storage --> tape vs. tape server --> tape). I'm finding similar results w/ Veeam as well; if we do a file to tape job from storage in the same rack copy files to tape the speed is slow (~50-something MBps), but if we have a file to tape or backup job that pulls the source data from the tape server locally to tape it's nice and fast (LTO-6, ~140-155MBps).

When you have 10Gbps storage fabric, 4Gbps LACP connection to your tape backup server (even w/ a single data stream going over one of the 1Gbps NICs), LTO-6/1.2Gbps via 6Gbps SAS, end user expectations on throughput are high. In theory Veeam should be able to pipe data from your storage fabric all the way through to that tape drive at full speed. For whatever reason Backup Exec couldn't do it - and support did confirm that, and Veeam v8 while does do better (~50MBps vs. BE's ~40MBps pulling from remote storage direct to tape), it should be able to do ~140-150MBps "pass-through" since it can run this full speed if the tape server is piping it from itself to tape. Of course we do expect some overhead somewhere, but ~50MBps vs. LTO-6's 160MBps becomes unusable when we get into no local LZ big enough to temporarily hold data, we need a tape cut fast, etc.

One other thing I haven't seen it mentioned, but if Veeam isn't aware of shoe shining, back hitching, etc. please do read up. Getting maximum throughput up to your tape drive is vitally important for a number of reasons please!

[micheltan]

It would be so nice if Veeam 9.0 is able to backup directly to tape. I hope R&D is working on this for future releases.

[foggy]

Thanks for your feedback, however Veeam B&R v9 will not feature this functionality.

[rreed]

By any chance has Veeam been tracking how much this feature gets requested? It seems like it gets asked about a lot. Myself included. Perhaps v9u1? v9.1?

[veremin]

We are aware of those requests, indeed. However, there are other features that have generated bigger demand among other users, such as Global Media Pool, native tape GFS, etc. What also distinguishes those features from the one discussed in this thread is the fact that those features do not appear to be against the recommended best practices. Thanks.