Enterprise users please read... BACKUP.FDB file and disaster recovery

I am in the process of implementing a disaster recovery solution for my company with true image enterprise server 9.1 on about 12 of our servers. I have a management server with a large drive array, and originally installed the Management console, Group Server, and Backup Server product on it. My idea was to push out the agents, set up group tasks to image the servers each night to disk, letting the Backup Server part of the product keep track of the images, doing automatic consolidation and such. This process would fire off late every night, and mostly just be incrementals and consolidations, then in the morning, I would use something like NTbackup to write all this to AIT5 tape to be carried offsite each day.

My day to day restore operations (if someone deletes a file, or if a server crashes) will be from disk back to the servers, so the tapes should only be needed if the building burns down, flood, tornado, etc. Once I realized that the Backup Server product named the image files random strings without the .tib extension, I found out that the BACKUP.FDB file is also very neccesary to restore from the image files. No big deal I thought, I will just make sure that file is written to tape everyday also, and could even be FTP'd offsite every day since it is small.

Now, having done a small scale 'disaster drill', I have run into what I think is the BACKUP.FDB file not only keeping track of the image files and their incrementals, but also the permissions and administrator/user account settings from the old backup server. So from a bare install of the Backup Server product, substituting the BACKUP.FDB file causes "denied access" to just about everything I try to do. I think it would all work out if I could rename the new Backup Server the same, and join it to the same domain, but that is kind of out of the question if I first need to restore one of my domain controllers to even have a domain. Kinda the chicken vs. the egg

Has anyone else noticed this or overcome it? From what I can tell so far, I am not going to be able to use the Backup Server part of the product and will have to create jobs that just do their images to a network share, which will be my backup server. That way, each of the server images and incrementals will be actual .tib files that can be restored from the ground up. The bad thing is, I'm going to have to come up with some way of automatically manging the number of files, as I can't let it grow and fill up my drives/tapes...

Please chime in with similar experiences.

 

Hello kidtriton,

Thank you for choosing Acronis Remote Server Backup Software.

Please notice that you can set Acronis Backup Server to back up directly to tape drive. Those archives will be restorable even without using backup server.

Thank you.
--
Marat Setdikov

 

No help to me, we want the backups live on disk for quick backup, and then write to tape using something else because (1) of the time it takes to do images one-by-one to tape vs. doing several to disk at the same time, and (2) we want our day to day restores to be done from disk so we don't have to have each day's tape onsite in case the building catches on fire, etc.

Doesn't really matter that much now though because we have given up on using the backup server feature due to it's picky database and guid files and just general flakyness. I'm just going to do images to the unc path of my backup server and then write them to tape.