kidtriton
April 17th, 2007, 03:37 PM
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.
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.