Recovery from Tape - Needs major work

[sreejiths]

+1

[pronto]

Hi Gostev

However, have you considered backing up your large file server with the File to Tape job instead? This job type creates tape backups which support fast file-level restores from tape - exactly what you are looking for. Please, do check it out and let us know.

A file level backup to tape over a Gigabit network is not advisable because much too slow for the drive. The drive will be throttled at best, and worst case it will go into a stop and go mode, which will negatively affect the life expectancy of the drive.

I wonder what's so hard about developing a single item restore from tape but at least we now have a clear announcement that this won't happen in the foreseeable future.

Anyway, we are handling our tape backup again with our old backup software, but we are confronted with 1.500 Euro maintenance costs every year, just so that you have an idea of what your denial costs your customers. Customer friendliness spells itself differently...

Thx & Bye Tom

[Ioannis.T]

hi pronto

Anyway, we are handling our tape backup again with our old backup software,

Can you please share the name of the product you are using to achive this, your old backup software that is.
Or if you do not want to post it in the forums just send me a pm.
I am really interested in checking it out, since so far, I have never tested a backup solution that does FLR from a VMDK from A tape. I have not tested every backup software so...
like csydas said in a earlier post, tapes are sequential mediums so random reads must be very sophisticated.

Thanks

[pronto]

Sevus,

I don't have any software that can recover individual files from a Veeam backup file on tape, I simply back up our large file server with our old backup software (Retrospect). The disadvantage of this is that it is quite slow, but the advantages outweigh the disadvantages, namely that I only have to store the large amount of data once on the backup server's storage (one week), the rest can be on tape. On the other hand, I can also recover individual files from tape relatively quickly.

With Veeam I only back up smaller servers, where you can easily leave several weeks on the backup server storage. And of course the replication of virtual machines is their core competence and they can do that really well. But in order to back up large servers cost-effectively, they unfortunately have no idea about. I don't know how they imagine keeping several terabytes of data on the backup server's storage for several weeks, or keeping several terabytes of free disk space on the backup server to restore tape backups if necessary. Two, three or four terabytes may still work, but certainly no longer with nine, ten or eleven.

For the long-term archiving of the smaller machines, I then also use Retrospect and simply back up the complete backup chain from Veeam to tape. This basically is almost the same as backing up to tape with Veeam itself, but it is recommended to only allow one application to access the tape library and tape drive.

That's what comes out of it, I just received the warning this morning:

"Backup location [E:\Veeam_Repositories] is getting low on free disk space (1,8 TB free of 21,9 TB)"

HTH & Bye Tom

[DavidCNZ]

Hi ,

I too would like a satisfactory way of achieving this. Our company standards require that we retain a monthly backup on tape. For one server the .vbk is 14 TB which makes it very difficult to restore files from. This conatins a single VM that is using deduplication on one of it's volumes so there's actually ~ 28TB of file data.

Would it be possible in a future version to have a "Synthetic File to Tape" backup that generates a "File to Tape" backup equivalent from the .vbk and .vib files on the fly as it's writing out to tape. That way it wouldn't be saturating network bandwidth when the tape library is attached to the same server that has the disk repository and provided it can generate fast enough wouldn't need nearly as much disk space as a whole copy of the .vbk would.

Regards
David

[csydas]

I simply back up our large file server with our old backup software (Retrospect). The disadvantage of this is that it is quite slow, but the advantages outweigh the disadvantages, namely that I only have to store the large amount of data once on the backup server's storage (one week), the rest can be on tape. On the other hand, I can also recover individual files from tape relatively quickly.

Tom, I don't think you're being entirely forthright here -- I took a peek at Retrospect as I'd love faster recovery from tape with Image level backups; looking at them, they're doing in-guest operations/volume backups, exact as Gostev recommended with a F2T backup of your server. It's not really a fair comparison here, since it looks like Retrospect offloads the files of the volume directly, not an image of the VM itself.

From their guide:

"The backup administrator creates a new Backup Set and does a Normal backup to it with a new or erased medium in the backup device. Because no files exist in the new, empty Backup Set, Retrospect copies all the selected files to it. The next day the administrator does another Normal backup to the Backup Set. Retrospect compares the selected source files to the Catalog File, then marks several new files and a few files which have changed since the previous day’s backup. Only these new and changed files are added to the medium previously used with this Backup Set (or a new medium if the other fills to capacity)."

This sounds just like a File Backup solution, and it's great it meets your needs, but you can already do this with Veeam.

I get what you're saying, you don't want to have to move the data twice, but what you're really wanting is a File Level backup solution for some of your servers, which you can do with Veeam Agents, I think.

I did have a crazy thought for a powershell script though to meet this desire...what about mounting an FLR session from the Image Level Backups and sourcing the FLR mount point for Tape jobs? You can do the Image Level archives, but also have a file level Tape out; it'd be copy-to only, of course, but better than nothing

Something like like:

https://helpcenter.veeam.com/archive/ba ... store.html

Use example 1 to launch the session, and store the sessionID and mount points (I'm sure they must be returned, I'm not in office to check right now), feed the mount point paths into a F2T job and fire it off, then close out the FLR Session when the job completes and have some watcher event that checks every so often on the F2T job for a success status.

Heck, I think we could get it doing even Storage Snapshots to tape with this...I'll try to cobble something together this week.

Only thing is, I'm not sure if incremental would be possible with this since we'd have a new mount point UUID each time, and I think the different path would make this not super possible without some additional array magic...I'd need to think on this a bit)

[pronto]

Servus Csydas,

[...]I took a peek at Retrospect as I'd love faster recovery from tape with Image level backups; looking at them, they're doing in-guest operations/volume backups, exact as Gostev recommended with a F2T backup of your server. It's not really a fair comparison here, since it looks like Retrospect offloads the files of the volume directly, not an image of the VM itself.

That's the first step. You create a file backup from the file server to the backup server in a disk backup set. This happens over the network and basically works the way Veeam does. Unfortunately, that's the part that's going on quite slowly with Retrospect.

I get what you're saying, you don't want to have to move the data twice, but what you're really wanting is a File Level backup solution for some of your servers, which you can do with Veeam Agents, I think.

What you overlooked when viewing Retrospect, is the ability to transfer one backup set to another. This may also work from a disk backup set to a tape backup set. It is therefore not necessary to make a file level backup from the file server directly to the tape, but can be transferred directly from the backup server to the tape. This has an immense speed advantage, in our setup approx. factor 3 and prevents a stop and go of the tape drive, if it does not have to wait for data from the network.

In principle, this is what Veeam actually does, it transfers a backup chain from disk to tape. The significant difference, however, is that with Retrospect I can access the backup set on tape exactly in the same way like the backup set on disk. I can open it in Restore Explorer, select a file to restore, and it's done. In Veeam I first have to transfer the entire backup chain from tape to disk again and that is exactly the difference...

I did have a crazy thought for a powershell script though to meet this desire...what about mounting an FLR session from the Image Level Backups and sourcing the FLR mount point for Tape jobs? You can do the Image Level archives, but also have a file level Tape out; it'd be copy-to only, of course, but better than nothing

I will analyze your workaround these days and see if we can avoid the two big problems with tape backups from Veeam. 1) No access to the tape with data coming from the network, resulting in 2) Access to data written to tape directly from the backup server without having to restore the entire tape first. These are the two requirements I have for a tape backup.

Thx & Bye Tom

[csydas]

No, I think I got it, but ultimately backup sets seem like just a logical unit for a collection of files, and ultimately there is either some proprietary blob or literally individual files on tape. Like, I'd be curious what we see if we dumped a tape written by Retrospect using scsi commands.

With Veeam, again, it's image level, so don't think of files, think of the VM's disks + config files -- this is why the idea of pulling an individual file out of a VMDK is a bit difficult for me to wrap my head around -- Veeam only would have knowledge of the files via indexing, and even then, you could at best know which block(s) need to be retrieved, but whether they're usable or not without the rest of the data isn't really clear to me (I've not looked into what sort of requirement that would be) But the point is the constituent components of a Veeam backup file are the VBK/VIB itself, and then the individual VM disks (VMDKs, VHDX, etc), not files. I think this is where there's a gap in agreement here, because I just cannot think on how to reliably pull a file out from two logical entities like that all on a tape medium without murdering the tape drive/tape.

But yeah, I think my idea should work, or at least I can't think why it wouldn't. When backups get mounted in Veeam for FLRs, they mount to C:\VeeamFLR; we've rsynced entire servers out of these folders terabytes at time, so at least rsync can grab'em, so I imagine you could do full backups to tape the same way and save yourself the "double copy" you need to avoid. (Which, I do get your need here, it's not like that is misunderstood)

[pronto]

Servus,

[...]but ultimately backup sets seem like just a logical unit for a collection of files[...]

This requires any backup software in any form, otherwise they could not preserve ACLs and file system metadata across platforms.

[...]When backups get mounted in Veeam for FLRs, they mount to C:\VeeamFLR; we've rsynced entire servers out of these folders terabytes at time, so at least rsync can grab'em, so I imagine you could do full backups to tape the same way and save yourself the "double copy" you need to avoid.[...]

But back to your solution [...] I haven't thought enough about your idea yet and also had some problems to follow all your explanations exactly - but - did I understand you correctly, you want to start a normal File Restore job of any backup from disk and use the mountpoint as source for a File Level Backup to tape?

Anyway, this idea is good [...] If it works with on-board resources, it is brilliant. I'll think about it in detail next week but this plan is better than mine, to be honest. Let stay us in contact for further detailed discussions...

Thx & Bye Tom

[csydas]

Evening Tom,

Sorry for my delay, but I tested this in our test-environment, and it works perfectly.

I even tried to make a simple PS script to handle it, but for some reason I'm too stupid to make the input functions work correctly :/

Code: Select all

add-pssnapin VeeamPSSnapin

#$VM = Read-Host -Prompt 'Name of Server for File Tape-out (case-sensitive)'
#$Job = Read-Host -Prompt 'Name of Backup Job (case-sensitive)'
#$Files = Read-Host -Prompt 'Path of Files to Backup'
#$server = Read-Host -Prompt 'Name of Mount Server where FLR is Mounted (As shown in Veeam)'
#$mediaPool = Read-Host -Prompt 'Name of Media Pool to backup Full Backups'

$VM = 'Source VM"
$Job = 'Name of Job backing up VM'
$Files = '/path/to/files/to/backup'
$server = 'mount server for backup files'
$mediaPool = 'Target Media Pool'

$result=Get-VBRBackup | where {$_.jobname -eq $Job} | Get-VBRRestorePoint | where {$_.name -eq $VM} | Sort-Object creationtime | Select-Object -First 1 | Start-VBRWindowsFileRestore
$flrmountpoint = ($result.MountSession.MountedDevices | ? {$_.DriveLetter -eq (split-path -Qualifier $Files)})
$file = $flrmountpoint.MountPoint + (split-path -NoQualifier $Files)
$tapeServer = Get-VBRServer -Name $server
$object = New-VBRFileToTapeObject -Server $tapeServer -Path $file
$tapejob = Add-VBRFileToTapeJob -Name "Tapeout from Backup of $VM" -FullBackupMediaPool $mediapool -Description "Tapeout from existing backup files from $VM Backup File. Files are retrieved from FLR Mount. No Restore to Original Location, only Copy To" -Object $object

Start-VBRJob -Job $tapejob -RunAsync

I don't know why, but PowershellISE gets grumpy if I use the -Prompt things; I'm not a Windows/Powershell guy so I have no idea why it's upset, but setting the variables manually works. If someone can point out what I'm doing wrong, I'd appreciate it.

Regardless, this will work for you. I cobbled this script together from some code I found on the powershell forum + just common sense.

This does have some limitations:

1. Full Backups Only
2. No Restores to Original Location
3. Performance likely will be impacted since you're reading from backup

But this should meet your needs.

[csydas]

Also, so sorry, I missed your primary question:

you want to start a normal File Restore job of any backup from disk and use the mountpoint as source for a File Level Backup to tape?

Precisely. I totally get your use case -- you don't want to transfer to your Repository twice or have to go over network to the Tape Server.

When Veeam mounts a backup file, it's mounted to a path (C:\VeeamFLR). I just figured, "it's a windows path, we can read from it, so tape should be able to also".

I only tested with a few dummy servers we have (maybe 30 gig of data total), but it was pretty fast. I imagine you could get a great one-off with this for periodic weekly or monthly backups.

What my script does is just auto-mate the process for a one-off job run, it starts the FLR, creates a tape job with the mount points, and starts the tape job.

Really, I'd love for Veeam to incorporate this as an actual function, as it's the easiest way to make a proper File Tape-out job for many servers. Hell, I even got it working with our Storage Snapshots, so we now have a direct Storage Snapshot > Tape solution. Our smart PS guys will make it cleaner, m but we can dump VMDKs like no one's business.

[Kwanda]

Hi Guys

has anyone gotten a solution to restore individual files from Tape without having to restore the whole backup?or at least a way to get it to restore faster

[veremin]

Currently, the described approach remains the same - we need to get a whole backup to repository first before we can restore a guest OS file from it. Thanks!

[Kwanda]

Hi Verenim

thank you for your response.

[pronto]

Servus,

When Veeam mounts a backup file, it's mounted to a path (C:\VeeamFLR). I just figured, "it's a windows path, we can read from it, so tape should be able to also".

when you mount a volume over the network to a local mountpoint it still remains what it is: a network volume. This doesn't solve the problem of limited bandwidth...

HTH Tom

[soncscy]

Hi Tom!

(Same poster, different account)

In fact, I believe with PS you can avoid this ) that's why I did the script.

I also noticed in v10 now the console mount can be stopped, so you can do this even better in v10.