Every product has to have a gimmick strong point to make it sell. Same as products that do Exchange mailbox level backup/restore, etc. The reality is this feature sounds good on paper, but in practicality is probably not useable for corporate users. Just like compression in many cases which you would think would always make sense. This is playing on the backup issue of so much data, but the management of the data is likely unwieldy. I think it could provide benefit for desktops that are deployed and reducing the amount of storage space to store the information. But, why even do that. A corporate image is used for everything these days. So, do not back it up at all and rebuild from the corporate image. The concept of My documents and settings is the answer, why? Everyone does an upgrade every 3 years anymore and you have to reinstall/move your data then. If done right, the My documents and settings approach can solve so many problems like this. So, look at the issue, if you have 10,000 users and there is 3GB, 20000 files of identical image. That is 30TB and 200,000,000 files. Every backup you will have to look at 200M entries to see if they are the same and you will have to manage at least 300 tapes to hold that, and at what expense? This problem is resolved with a little discipline.
Some day Microsoft will fix this and the "linklist" on the image will be read only meaning there will be a image stamp for the programs and OS. All data will be stored in "user storage". That is the way the mainframe has worked for years. The catalogs to where the data, the security database, and the user data volumes are all that are needed on a backup in a cloned MVS world now. One image fits all. Like mainframes, the wantabies will figure out the value while the dinosaur moseys along having a nice day. But you wouldn't find that in a PC magazine. -----Original Message----- From: StorageGroupAdmin StorageGroupAdmin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 13, 2002 6:17 PM To: [EMAIL PROTECTED] Subject: Re: PC Magazine Enterprise Backup Article - NO MENTION OF 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. -----------------------------------------------------------
