Some assistance if possible!

[steelbubble]

Hi there,

 

I was wondering if someone could offer clarification on the backup strategy we currently employ in our workplace. I have two problems with our setup at the moment.

 

Overview:

Retrospect 6.0 Multiserver (on all servers)

Backup Set storage type for all servers is set to "File"

File Server contains a Sony AIT2 autoloader (handles 4 cassettes)

 

We backup all our servers to a file server with roughly 400GB of drive space (2 volumes at 223GB each) using a "file" backup storage type for each individual server.

 

My first problem is thus: when backing up our main data store (roughly 115-120GB) the backup performs perfectly (with some open file errors) and I can see a 115Gb *.rbf file. However if I choose to perform a restore using the succesful backup, when I try and select the E: volume snapshot of the backup I receive the error message "Snapshot cannot be found...this occurs when a backup fails, snapshot not saved...". I do not understand this as the backup DID complete successfully(although with open file errors). I do not have this problem on our other server *.rbf files which are between 30GB and 90Gb. Is there a size limit on a *.rbf that is causing this problem?!

 

My second problem: I cannot find a good backup strategy to use with the autoloader. I would like to achieve a backup strategy that allowed me to a). Backup the File server every day Only require to change the autoloader magazine once a week.

 

Any advice on the above would be greatly appreciated!!

 

Best regards,

 

Steelbubble

 

 

[AmyJ]

Quote:

---

Is there a size limit on a *.rbf that is causing this problem?!

 

 

---

 

No, there is no size limitation. Is this problem reproducible? Have you tried selecting other snapshots of the same volume from the backup set? Do you see the same results? Does a brand new backup set containing this drive produce the same error? Have you tried using a Disk backup set, rather then File? 6.0 and later allows for backing up to hard drives with Disk backup sets.

 

Quote:

---

My second problem: I cannot find a good backup strategy to use with the autoloader. I would like to achieve a backup strategy that allowed me to a). Backup the File server every day

Only require to change the autoloader magazine once a week.

 

---

 

How many backup sets do you want to use? How often do you want to rotate them? Are you using Proactive Client backup? How much data is changing? What is the capacity of the tapes? How much data are you backing up? Without more detailed information about your setup, it's not possible to provide very meaningful suggestions.

[steelbubble]

Thanks for the reply. To answer your questions:

 

1) Yes the problem is reproducible, every snapshot of the volume in this backup set produces this error, even though the other two volumes in the backup set are fine.

 

2) Yes, the exact same result is shown for every snapshot of this volume.

 

3) Yes a brand new backupset containing the drive produces the same error.

 

4) I would like to use two backup sets for use with my autoloader

 

5) Yes we are using proactive backup (not sure what relavance this has?)

 

6) AIT tapes (400GB with compression)

 

Thanks for the help.

[AmyJ]

Please try a Disk backup set, rather then a File backup set, and see if you have any better results.

 

 

 

Also, check the drive in question with a disk utility, such as Norton or McAfee.

[powermeck]

steelbubble,

 

 

 

here's the secret to our backup stragey with a tape library, and it has proven to be pretty good:

 

3 Backup sets, Set A, Set B, Set C, each starting on Friday night with a recycle backup and continuing with incremental backups during the week. All the tapes for each backup set fit into one magazine.

 

We start on a Friday night with a recycle backup to, for example, Backup Set A. The recycle backup erases all tapes, resets the backup catalogs, and creates a complete backup of all machines. The backup window is from Friday night, 5 p.m. to Monday morning 8 a.m. - way more time than it needs. Monday night at 5 p.m. an incremental backup to Backup Set A starts, stops on Tuesday at 8 a.m., and is being repeated until Friday morning. On Friday night (before 5 pm.) we remove the Backup Set A magazine and store it offsite. Backup set B magazine goes in, and the recycle backup starts. The following Friday Set C goes in, Set B goes offsite, Set A is onsite.

 

Confusing, no? It works perfectly for us.

 

 

 

Cheers

[steelbubble]

Thanks for the advice Amy and Powermeck.

 

I think the problem we are having with our current strategy is that we are trying to backup too much data onto our backup set (tape ejects and waits for another magazine). I will reduce the amount needed to back up and try your strategy powermeck.

 

Thanks again,

 

Steel

[powermeck]

Quote:

---

steelbubble said:

Thanks for the advice Amy and Powermeck.

 

I think the problem we are having with our current strategy is that we are trying to backup too much data onto our backup set (tape ejects and waits for another magazine). I will reduce the amount needed to back up and try your strategy powermeck.

 

Thanks again,

 

Steel

 

---

 

Hey, no problem Steel. And - you are on the right track, don't back up everything. Our strategy goes towards splitting the hard drives up into an OS partition which gets imaged regularly, and data partitions that get backed up. As applications tend to be interwoven with the OS they go into the OS partition. This will save you a lot of backup time. Actually (hint, hint) we are talking a lot about backup strategy in the 3rd edition of The Backup Book by Dorian Cougias et al. It will be hitting the bookstores next week.

 

good luck

powermeck