Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have backup exec 2010 R2. Going to be upgrading to 2012 here in the next day or two. I have several servers onsite and 4 remote servers. To backup the 4 remote servers to the tape library device I have takes way to long as it is slow over the connection and only one job runs at a time. Doesn't end nearly in enough time. So my solution was to backup all 4 remote servers to a disk folder. One folder for each site all listed under devices. I then have a final job of the night that backs up those folders to tape. All is well I thought, as all 4 remote sites backup at the same time, gets done fast as it is to disk.

Though, trying to restore data from a month or two back is proving to be a pain in the arse. I am currently struggling to recover some data. I have to inventory the tape, catalog it, then restore the disk folder, then inventory that, catalog that and look for the date and restore from it. Though, it is not working as smoothly as it should. Catalogs are failing and I am not getting the data.

There has to be a better way. Any suggestions on a better way to backup this data for easy recovery?

share|improve this question
1  
Why do you have to catalog the media? What is the Catalog retention set to? –  joeqwerty May 29 '12 at 18:38
    
Don't use tapes? –  Lucas Kauffman May 29 '12 at 18:38
    
Lucas: I'm pretty sure the Symantec best practice recoomendation is to perform B2D then B2T. I've been doing B2D then B2T backups for years. The B2D backups run much faster, reducing the production backup window significantly and multiple B2D backups can run concurrently. In general, restores are much faster as well... as long as you're restoring from backups that still reside in the B2D folders. Older backups that have been purged from the B2D folders do require a two stage restore though, first restoring the B2D backups from tape, then restoring the data from the B2D folders. –  joeqwerty May 29 '12 at 19:57
    
@ joeqwerty, thanks, that sounds exactly what I am doing. I am trying to get away from that two part restore going a way's back. Some reason, some of mine are failing. I restore the folder, then I catalog it so it will show up on the restore list on the wizard, and it will error out and say it failed catalog and I don't see that date on the list of possible restores. –  jherlitz May 29 '12 at 20:24
    
also, the retention is set for over a couple months, so if I have to go farther back then I have to catalog. Yes, we have users that won't realize something was deleted or knows it was, but doesn't ask until they realize, that they still need it. Frustrating. –  jherlitz May 29 '12 at 20:25

1 Answer 1

This is the intention of the tape. To store large volumes of data, instead of being fast.

I suffer the same "pain", when i have to restore just one mailbox on my job; Put the LTO's on the library, copy to disk, create a new temporary vm, copy the content to /var/vmail...

But you know, if the user deleted data during the last 5 days, we have 2 different Pools on the same tape library(22 slots), and we just withdraw from the library the "Copy of the Backup" tapes, to have some "minutes" of advantage during a restore.

share|improve this answer
    
We are pretty similar then. My library has two drawers, the first is filled up with tapes and is used for nightly incremental s. I can go back quite a few days with those. Then the second drawer is for weekly full's, server full's etc. It is my remote sites that are killing me. –  jherlitz May 29 '12 at 20:21
    
I know that this is a "dumb" solution, but we had to buy separated tape libraries on our remote sites. Sending data through OpenVPN+MPLS was a pain too.. ..im thinking on a solution. –  nwildner May 29 '12 at 21:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.