I once used a mainframe based backup product called 'Harbor'. This product had the feature you mentioned were it used pointers to a single copy of a file that existed on multiple files.
What I would ask is how does the application store all the 'other' data associated with the file, ie was it NTFS on server 1 but not on server 2, security keys, compressed or not etc etc. Storing this info would not seem insurmountable but then it becomes a question of the cost of CPU and time to process this information verus the cost of storing multiple copies. Kelly's point of excluding files such as WINWORD.EXE or the entire base OS is valid assuming you have a method to ensure that the base environment is standard across all servers - in other words The Standard Operating Environment. For most companies implementing or who have implemented the SOE structure, they have to have a method to 'push out' the SOE therefore by default solving the first part of the BMR restore process (ie building the base OS including the TSM client) My opinion (for what it is worth) is that with the SAN environment becoming common place the standard ideas for BMR processing needs to be re-worked. The following is something I would like to test further..... (For the following points I am referring to the EMC product offerings as that is what we use and have had success with) 1) For critical or servers with large amounts of data they should be on the SAN therefore a localised failure in the server hardware will require at worst minimal data restore. If you do not boot off of the SAN then only the OS would need to be recovered. Maybe even data that was corrupted due to an unclean shutdown. 2) Restoring from total SAN based data corruption can be facilitated by disk mirroring with Timefinder / Snapview type products. Major databases are a classic candidate including the TSM server itself. 3) For full DR and a combination of the two previous scenarios the remote mirroring (ie SRDF) is the option for those with multiple sites. Combine this with booting off of the SAN then your BMR solution would involve nothing more that sourcing the hardware and you SAN zoning. The second site option could even by supplied by you DR service provider in the form of a dark site. For TSM clients not on the SAN....... Base Operating System (the SOE environment) could be on the SAN therefore in the event of a DR: - Source you Hardware and Install a Temporary HBA card - Connect & boot your new hardware from the SAN. The SAN based OS would have the appropriate TSM authority to restore the 'lost server'. - Restore the entire image of the lost server to the local disk on the new hardware. - Remove the HBA & reboot With standardising hardware and the hot pluggable drives in most new equipment the restore server might be a permanent SAN connected host and you could simply pull the drives and put them in your replacement server. Peter Griffin Sydney Water >>> [EMAIL PROTECTED] 02/14/02 03:46am >>> I'm not an expert with ADSM, but does ADSM have any of the advanced features that this article talked about? Can it back up a file only once for all the computers that have a copy of it? Or will it back up Winword.exe 5000 times for my whole organization? We're starting to look at what it will take to offer backup for the entire campus, and some of these advanced features would be desirable. Steve Cochran Dartmouth College ----------------------------------------------------------- This message has been scanned by MailSweeper. ----------------------------------------------------------- ----------------------------------------------------------- This e-mail is solely for the use of the intended recipient and may contain information which is confidential or privileged. Unauthorised use of its contents is prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and then delete the original e-mail. -----------------------------------------------------------
