Recovery from Tape - Needs major work

[jazzoberoi]

+1 : Granular file restore for me, but happy with single VM restore also.

[ddayton]

+1. Granular file restore would be my vote as well. I have never needed a VM restore yet from disk or from tape storage. I guess I'm one of the lucky ones.

[sibinsam]

Will this feature be included in patch 2?

[veremin]

I think Dmitry was talking more about potential features for one of the next releases, rather than patches.

[seadave]

Both of these options should be available. At the very least allow a single VMDK (some of us with multi-2TB VMDK VMs) to be restored and then mounted to retrieve the file, but the entire job only indicates a lack viewing this from the user perspective. If the current situation remains, the system should be monitoring the BR and should alert the user to the fact that they will NOT be able to restore job X via tape because there isn't enough free space. That could cause a major crap storm for someone during their hour(s) of need.

[martin_nz]

Granular restore off tape would be fantastic.

[20100]

Please add to me too.
Priority for me would be VM first, and then granular file restore. Whatever is easiest and released quickly. Either is better than the full tape restore as per now

[jacob.estrin]

My Preference would also be granular file level restore if possible (Guest OS Files that is).

I would not scoff at vm restore mind you...

[Meyercord]

In day-to-day operations, it's much more common for me to need recovery of a single file or folder than a full VM; however those requests are typically pretty low priority. In a disaster event, its more likely that a full VM or multiple VMs would be required. In either case, recovery direct from tape would be very important for many reasons, including the time and cost to download a complete backup set from a VTL cloud archive compared to downloading just the minimum required media, as well as the disk space required to first restore the entire backup to disk. In a disaster event, when we are operating on minimal resources, our available storage is likely to be especially limited.

[actiefnet]

Is there any expectation on when this will be available? Proposing VEAAM to several new customers, but they probably won't accept without this feature. Not having it makes tape support useless in a lot of cases.

[veremin]

We do not publish our roadmap. But should this feature be implemented, it would be included in a major release, rather than just in a patch due to the amount of changes needed. Thanks.

[AaronD]

+1 too here. We've got several big file server that we archive to tape. Restoring a single 5TB VDK for for a couple of files complicates the restore procedures a lot.

+1 for file

We have ran into this situation before. Needed to restore one file from our fileserver but first had to restore a 1TB vbk. Really increases the recovery time.

Same thing with our 2TB SQL server. Plus we need to ensure we have 2TB free space to restore the vbk when really we just need to restore a 50GB mdf.

[Dima P.]

AaronD,
Thank you for sharing. By the way, have you considered backing up a file server data directly via file to tape job?

[sims]

+1 too here. I've got a big file server that we archive to tape. I need to restore 1.5TB for restoring one files ...

[PenguinSSH]

AaronD,
Thank you for sharing. By the way, have you considered backing up a file server data directly via file to tape job?

I know you were speaking to AaronD, but considering the performance of file to tape job, this would not be possible for us. It looks like a perfect solution in theory but doesn't really scale.

-Millions on small files so slow copy
-Doesn't backup permissions

In the case of a disaster, we would need these permissions back.

EDIT: On top of this, we would need a copy on disk and 2 copies on tape. One retained onsite and the other offsite.

[Gostev]

Just wanted to chime in with a comment.

Going directly to tape is basically against our reference architecture. Veeam is a disk based backup solution, so we expect users to backup to disk first and foremost - and use tape for long term retention and archival. This approach is also known as D2D2T (disk to disk to tape).

With this architecture, vast majority of recoveries will be served from disk-based storage, which will provide fast recovery times. Tape will typically be used in rare circumstances when primary backup target is lost, in which case you would need to restore the entire backup files anyway to have your backups readily available. Also, you will need tape to recovery something from a very old restore point (for example, for investigations) - which is even more rare occurrence.

This is just to explain the architecture that we are evolving our product around, and why we don't provide some feature that legacy products built around backing up directly to tape (at least originally) do provide.

The feature being discussed is certainly on our roadmap, but - as with any feature that goes against our reference architecture - its priority is significantly lower than some other pending tape features. Thing is, trying to be everything for everyone, supporting all possible backup architectures and deployment scenarios is simply a recipe to disaster (because as a result, none of them will work well).

That said, you can still confidently expect this feature to be delivered down the road (just later, rather than sooner).

Thanks!

[PostBE]

Gostev I think you may have misunderstood this thread, We are talking about restoring back from tape as not every organization has the money/infrastructure to implement a large purely disk based backup system so in my case we can only keep two weeks of backups on disk before we have to send this to tape, This is well within your architecture.
If you aim too high with this product and cater only for the large corporates who can afford to throw copious amounts of money into Tb of disk based storage/deduplication devices then the rest of us who at the moment have a very ordinary experience with the 'bolt on' that is the tape portion of your product could have to look elsewhere again.
Our company came to you from Symantec after they stuffed the whole backup exec 2010 thing up but ironically their tape based side of that product was extremely mature in comparison.
What I'm trying to say is please don't neglect your user-base that still relies on tape for archiving and ultimately restores as waiting hours/days for the files to restore just won't cut it when the proverbial hits the fan.

Thanks.

[adrien.herve]

Completely agree with you PostBE. I'm really disapointed with this, I have a large VBK and large VIBs and I can't replicate my backup off-site because I don't have the bandwith to do this. So my only option for doing my daily off-site backup is the tape. After saying this, for deduplication reasons (and storage consideration) I need to have big jobs with a consequent number of VMs and if I need to restore from tape I need to restore the whole VBK for a single file (around 8TB) which is not fair. I'm currently blocked by this on my project and try to find solutions with my reseller/partner (maybe splitting jobs and increase storage).
Veeam is an awesome software and it's pretty cool that you want to find the fastest way to backup but don't forget that we need the fastest way to restore too. Please don't forget tape users, I know this is not "your reference architecture" but the end of rule says "2 differents medias with 1 off-site" and when you have TBs and no bandwith you don't have much solutions to respect this.

[BKeane]

+1 for granular restore. Having to restore a 4tb vbk to get one file is a bit cumbersome.

[danc]

+1 for granular restore for me as well! Otherwise I'll have to keep Backup Exec for a little while longer as it supports file restores directly from tape!

[krogerss]

+1 for me as well. Not sure my supervisor would have jumped ship to Veeam so quickly if he had known this.

[ChrisBailey]

I completely agree with this thread. I've been using Veeam since October of last year and it has been absolutely amazing... today I needed to go back to tape for the first time, I need a 20MB file and I am being forced to restore 2.5 TB onto disk. I don't have that kind of disk space laying around... I also need the file quickly which can't be achieved when I have to wait for such a long restore.

I know that Tape is fairly knew in Veeam... but you should be able to select individual files to restore... even if I could just get the full VM I'd be much happier than I am right now.

[Treeeman]

+1 for me as well.

[sentenza]

I can only add +10...

I found no other solution but to reduce the size of my jobs and run more in parallel. This makes things more complicated than they should be and creates more opportunities to miss machines in the job selection. I ended up with some jobs containing only one machine: my file server is ~8TB with a Veeam repository finally at ~5TB. This is still a lot of "scratch" space and a lot of time to restore 1 excel file

I can't reduce more than 1 job per machine and can't wait 10 hours copying from tape (5TB on LTO6) to restore one single file: granular restore is more than needed.

[B.F.]

Veeam is a disk based backup solution, so we expect users to backup to disk first and foremost - and use tape for long term retention and archival.

Contrary to what end users keep telling us, disk is NOT cheap (when dealing with enterprise grade MSA's) Our File Server is large and we had to make a decision when it came to planning the route for that VM's backup. We decided on replicating to a remote site. Spin up time is really fast if the primary site were to go down and we still could recover an individual file. Having it offsite was another win since we have adequate bandwidth. Backup to local disk would be redundant and unnecessary since we are using BE for data file to tape backups. Full backup once a week with differentials to follow. This means we only need 2 tapes to be offsite to be semi-current. (the Full and the last differential).

In our scenario, we actually DO "backup" to disk via replication. However, Backup to Tape is not an option since there is no actual backup (VBK). If we were to drop BE (which we really want to happen), we would be forced to use File to Tape backup which can only do Full and Incremental backups. The consequence of moving from Differential to Incremental means we then need to get a larger tape safe to hold the full chain of tapes

Short Term: Please include a Differential option for File to Tape. I believe it's just a matter of not flipping the file's archive bit until a full backup is done.

Long Term: Being able to pull a file from the VBK on tape would be greatly appreciated.

Thanks

[veremin]

Short Term: Please include a Differential option for File to Tape. I believe it's just a matter of not flipping the file's archive bit until a full backup is done.

Can you clarify your request a bit? I'm wondering because file to tape job already has incremental option, meaning that if it's setup properly, starting from the initial cycle it will archive only new or modified files from a given directory.

Also, if you'd like to discuss implementation of file to tape job, it'd be better to create a separate discussion in order not to overfill current one (that discusses tape recovery capabilities) with irrelevant matter.

Thanks.

[B.F.]

Can you clarify your request a bit?

... it'd be better to create a separate discussion...

Yes, a separate thread has already been made
http://forums.veeam.com/tape-f29/differ ... 28341.html

Thanks

[Dima P.]

Hello guys,
Once again thanks to all of you for sharing your thoughts. While this conversation is still open and we are tracking every single post in this thread I wanted to leave a friendly reminder to newcomers.

The original question was what type of restore from tape media you need the most – file level recovery from backup or VM recovery from backup on tape? Please don’t forget to post your use cases.

[MathewERA]

Hi,

+1 to this. I think file level recovery from tape would be handy. Quite often I have to restore archive data and having to restore TB's worth do data to get to a single 1mb file is pretty frustrating.

Cheers

[AJ83]

File level recovery from VM inside VBK on tape would be very much appreciated, but in a disaster recovery scenario (in which you would rely on the tapes), i would like to be able to get my AD servers restored out of the VBK on tape.

So restore single VM from vbk on tape would be my priority.