Re: Keeping an handle on client systems' large drives
Hot Diggety! Seay, Paul was rumored to have written: Ask them where they were on 9-11-2001. Are they totally brain dead? Ahhh, so that's what you referred to in passing in the other post. That's all right, and understandable. I have a first rate appreciation of this. If you'll allow me to indulge briefly on a tangentially related (but not completely) issue on this list, just once... I used to be a VMS admin. Best, most robust OS that I ever worked with - probably true for the IBM mainframes but didn't work much with them, alas. (A little OS/400, DOS/VSE, and one or two other related OSes) Anyway, come post-9/11, a *lot* of financial firms were in a world of hurt. The ones who planned and re-tested over and over again, each year, for an alternate site a good distance away from NYC, was able to reopen for business only a few days later. Many were based in NJ or about an hour west/north of NYC... one was even based not too far from home, their DR site being about 4-5 hours northwest of NYC. Around this time, I heard that Compaq (company that bought out DEC) was making a lot of frantic calls all around the country seeking out high end machines such as the AlphaServer 8400s and VAX 7000s...that had been discontinued for perhaps 10 years since, because a lot of customers were suddenly calling in for warranty replacements (under their expensive support contracts) in NYC and DC -- you can guess what kind of customer it was in DC. How desperate was Compaq? They were calling up even third level resellers of used equipment that they would normally never ever think of talking to. Compaq was in a nasty hole, because they had run out of set-aside reserve spares. Fab plants *long* since shut down...they can't just take the original plans and re-fab, since the engineers no longer there... I'm not sure how they eventually resolved that... probably offered newer machines to customers and provided migration assistance at Compaq's cost, is my guess. But what the bean counters don't realize is that it doesn't take a catastrophic national event to mean a bad effect on the business bottom line, which I find unfortunate. Can be all sorts of more 'mundane' (albeit not very common) events such as that train which burned in a Baltimore tunnel and closed a part of downtown near Oriole Park at Camden Yards. My company (used to also own a telco) was personally affected by an homeless man burning something in a former abandoned railroad tunnel that melted fiber optics and took out OC-12 to the area for 12+ hours, with a nice number of servers based out of here. It doesn't have to be a corporation for a nasty disaster to mean bad things for their bottom line. I am very well reminded of a colossal failure at an academic institution almost a decade ago that was a chain of events ultimately resulting in failure of a critical drive in a RAID-5 array, and the tapes weren't really usable for recovery...which they found out the hard way. An entire semester of classwork was effectively disrupted, with much data lost, before they were finally able to convince DEC to send out the very best people to recover about 80% off the RAID-5 array through some custom work. So many classes, projects, research papers, etc. were affected that it just simply isn't funny. Same place where if the IBM mainframe ever went down, school was closed for the day. (Happened only once ever, to best of my knowledge.) ...and that is truly unfortunate, that the people who are actually tasked to make things happen, like us, understand and appreciate, whereas others higher up may not share the same view, knowledge, and experience. In a D/R scenario, it also behooves you to know your power sources, how they kick in, at what levels, how fast/when, evacuation plans, how to config PBXes, have emergency equipment handy (eg flashlights), and a million other details. Hardware that can be quickly hooked up/activated, written step by step plan nearby, software CDs handy if needed, dry runs done, backups/restores/app operation verified, and all of this tested once or twice a year depending on level of need and impact, etc. Still, I resolve to do my best to do whatever I can realistically do. :) With that said, I now return you to the normal *SM discussions. ;) (with the reason for copy stgpools driven home ;) ) -Dan Foster IP Systems Engineering (IPSE) Global Crossing Telecommunications
Re: Keeping an handle on client systems' large drives
Actually, our company policy is if you do not put it on a LAN drive share, it does not get saved, period. A few of us are trying out the desktop approach to see if it works for laptops. So far, so good. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Dan Foster [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 12:27 AM To: [EMAIL PROTECTED] Subject: Re: Keeping an handle on client systems' large drives Hot Diggety! Seay, Paul was rumored to have written: What you have to do is revisit what you are saving and put in exclude.dirs for all directories that contain software that can be rebuilt from a common desktop image (hard drive replacment). Have your users save their documents in specific folders and only back them up. Then they just have to customize their desktop configure their node name in the dsm.opt and restore the stuff that is backed up. This is the trade-off. Makes sense. Basic education + cost saving vs expense from a brute force approach. The trick is to have education that works well for a wide range of users, with differing expertise, and to also clearly communicate expectations (if you save anywhere else, you won't get it back!). Now that sounds like I also have to train them to not just blindly click whenever an application offers them a default directory (often within app area) to store documents in. Perhaps a small data area carved out on the hard drive, like say, 5 GB partition for user documents as Z: or whatever, and similiarly for other platforms (/userdocs/user as a symlink from ~user/docs or whatever), to provide a consistent and easy-to-use area for end user, yet predictable area for mass-deployed *SM configurations to use. I'm sure that the IT shop can help out significantly if they're able to preconfigure these settings within each application before users gets their hands on the machine. Hard part is when not every place has that luxury, especially at smaller places where end users may be configuring everything on their own. Anyway, the overall education/training approach is definitely cheaper than having to save everything on the HD, I do agree. ;) -Dan Foster IP Systems Engineering (IPSE) Global Crossing Telecommunications
Re: Keeping an handle on client systems' large drives
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Foster Not every site is lucky enough to be able to convince the beancounters the merits of having a backup system that keeps up with the needs of the end users, even if it means one has to explain doomsday predictions on the business bottom line -- they invariably hear that then say Oh, pshaw, you're just exaggerating because you want money It sucks to be the one that's right ;) And the ones who warns well before a nasty event occurs may also be the first one to be fired out of spite after something happens and gets the blame for not having prevented it. There is only one thing that will convince the beancounters that backup resources must be kept to adequate levels: one bad day Put your objections in email, send that email to those who matter, and *keep* *a* *copy*. Gently (but regularly) remind the powers-that-be that your backup resources are inadequate. In the meantime, aggressively filter what is being backed up. An increasingly large amount of data is going to files with extensions like .nrg, .wmf, .mp3, .rm, and .gho (my current unfavorite). Don't back 'em up. -- Mark Stapleton ([EMAIL PROTECTED]) Certified TSM consultant Certified AIX system engineer MSCE
Re: Keeping an handle on client systems' large drives
Microsoft Policy Editor. I hate it personally, because I do know what I am doing, why, and where, but it does force the default data directories for the great unwashed to be on the data server. It takes a conscious (and annoying) effort to save something on your local drive. - Kai. -Original Message- From: Dan Foster To: [EMAIL PROTECTED] Sent: 6/13/02 9:24 PM Subject: Keeping an handle on client systems' large drives I've always been curious about something. How do you keep an handle on the fact that commodity PC storage is growing at a far faster rate than tape capacity/system is? For example, if I had a small LAN of about 300 PCs -- let's say, an academic or corporate departmental LAN environment... each has at least a 40 GB HD, and probably a fair amount of apps and files on them. In the stores, I see drives up to 160 GB, with even larger ones on the way! So let's say, an average of 25 GB utilization per system... a single full backup would be about 7.5 TB, which is quite a few tapes ;) Not everybody is using LTO or higher capacity. So do those sites rely purely on the incrementals to save you? Or some site specific policy such as tailoring backups to exclude (let's say) C:\Program Files, or some such...? Just wondering. Not every site is lucky enough to be able to convince the beancounters the merits of having a backup system that keeps up with the needs of the end users, even if it means one has to explain doomsday predictions on the business bottom line -- they invariably hear that then say Oh, pshaw, you're just exaggerating because you want money It sucks to be the one that's right ;) And the ones who warns well before a nasty event occurs may also be the first one to be fired out of spite after something happens and gets the blame for not having prevented it. -Dan Foster IP Systems Engineering (IPSE) Global Crossing Telecommunications
Re: Keeping an handle on client systems' large drives
Mark, I know about mp3s and we do exclude them; what are : .nrg, .wmf, .rm, and .gho? -Original Message- From: Mark Stapleton [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 8:24 AM To: [EMAIL PROTECTED] Subject: Re: Keeping an handle on client systems' large drives From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Foster Not every site is lucky enough to be able to convince the beancounters the merits of having a backup system that keeps up with the needs of the end users, even if it means one has to explain doomsday predictions on the business bottom line -- they invariably hear that then say Oh, pshaw, you're just exaggerating because you want money It sucks to be the one that's right ;) And the ones who warns well before a nasty event occurs may also be the first one to be fired out of spite after something happens and gets the blame for not having prevented it. There is only one thing that will convince the beancounters that backup resources must be kept to adequate levels: one bad day Put your objections in email, send that email to those who matter, and *keep* *a* *copy*. Gently (but regularly) remind the powers-that-be that your backup resources are inadequate. In the meantime, aggressively filter what is being backed up. An increasingly large amount of data is going to files with extensions like .nrg, .wmf, .mp3, .rm, and .gho (my current unfavorite). Don't back 'em up. -- Mark Stapleton ([EMAIL PROTECTED]) Certified TSM consultant Certified AIX system engineer MSCE
Re: Keeping an handle on client systems' large drives
This is always a trade off between what is practical-possible-available-affordable and the backup coverage you need. But I would like to put in a word AGAINST the if they don't save it in the right place they don't get it backed up philosophy. I'm not criticizing you guys specifically here, this is just MY point of view on one backup philosophy issue that resurfaces continually here on the list. Partial backups + user rules has always been the accepted solution for IT support, because backing up everything in the environment is hard, and it's expensive. So backing up just the network drives or just the x directory is the accepted tradeoff, and you teach your users if you don't put it on the x directory you won't get it back. But, really, when that happens, who wins? If a user spends two days working on a powerpoint presentation, and accidentally trashes it, and it isn't backed up because they didn't save it in the right place --who pays, in the long run? Who are these people, and why does your company/installation have them working in the first place? My argument is that if you can afford to lose that person's time, you have too many people working for you. Most sites I deal with are trying to run VERY lean on staff, and especially with engineering and software development sites, the professionals are VERY EXPENSIVE PEOPLE. Has anyone in your company ever really figured out what it costs when a software developer/engineer has to recustomize a workstation with a bunch of software development tools on it when the hard drive crashes? Have you ever tried to rebuild from scratch a workstation that is running multiple versions of programmer development kits, when you only have backups of the data files? Do you know how many hours it takes and how much that person's time is worth? What it costs to miss a deadline? Doesn't productivity matter? Or are all the staff in your company useless drudges whose time has no value? (think carefully before answering that one! :) HOW DOES IT MAKE ECONOMIC SENSE TO SCRIMP ON BACKUP/RECOVERY SUPPORT, AND WASTE PEOPLE TIME INSTEAD? My position is that instead of choosing to educate users to work around our backup support limitations, we should be EDUCATING MANAGEMENT to actually LOOK at how important their people time is to the company's welfare. I do realize that we have come to this state because in too many companies, IT infrastructure is considered an overhead expense instead of a critical resource, and IT managers eventaully get beaten down in the budget battles and eventually give up trying to keep up with organizational growth. But keep repeating this over and over, to EVERYONE in your installation: EVERY TIME you buget money to buy storage, YOU MUST INCLUDE the cost of backing it up. Period. Thus endeth my soapbox speech for the day. Time for lunch.. Wanda Prather Hot Diggety! Seay, Paul was rumored to have written: What you have to do is revisit what you are saving and put in exclude.dirs for all directories that contain software that can be rebuilt from a common desktop image (hard drive replacment). Have your users save their documents in specific folders and only back them up. Then they just have to customize their desktop configure their node name in the dsm.opt and restore the stuff that is backed up. This is the trade-off. Makes sense. Basic education + cost saving vs expense from a brute force approach. The trick is to have education that works well for a wide range of users, with differing expertise, and to also clearly communicate expectations (if you save anywhere else, you won't get it back!). Now that sounds like I also have to train them to not just blindly click whenever an application offers them a default directory (often within app area) to store documents in. Perhaps a small data area carved out on the hard drive, like say, 5 GB partition for user documents as Z: or whatever, and similiarly for other platforms (/userdocs/user as a symlink from ~user/docs or whatever), to provide a consistent and easy-to-use area for end user, yet predictable area for mass-deployed *SM configurations to use.
Re: Keeping an handle on client systems' large drives
.wmf is the Windows Media File format -- Joshua S. Bassi Sr. Solutions Architect @ rs-unix.com IBM Certified - AIX 5L, SAN, Shark eServer Systems Expert -pSeries HACMP Tivoli Certified Consultant- ADSM/TSM Cell (415) 215-0326 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Prather, Wanda Sent: Friday, June 14, 2002 8:13 AM To: [EMAIL PROTECTED] Subject: Re: Keeping an handle on client systems' large drives Mark, I know about mp3s and we do exclude them; what are : .nrg, .wmf, .rm, and .gho? -Original Message- From: Mark Stapleton [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 8:24 AM To: [EMAIL PROTECTED] Subject: Re: Keeping an handle on client systems' large drives From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Foster Not every site is lucky enough to be able to convince the beancounters the merits of having a backup system that keeps up with the needs of the end users, even if it means one has to explain doomsday predictions on the business bottom line -- they invariably hear that then say Oh, pshaw, you're just exaggerating because you want money It sucks to be the one that's right ;) And the ones who warns well before a nasty event occurs may also be the first one to be fired out of spite after something happens and gets the blame for not having prevented it. There is only one thing that will convince the beancounters that backup resources must be kept to adequate levels: one bad day Put your objections in email, send that email to those who matter, and *keep* *a* *copy*. Gently (but regularly) remind the powers-that-be that your backup resources are inadequate. In the meantime, aggressively filter what is being backed up. An increasingly large amount of data is going to files with extensions like .nrg, .wmf, .mp3, .rm, and .gho (my current unfavorite). Don't back 'em up. -- Mark Stapleton ([EMAIL PROTECTED]) Certified TSM consultant Certified AIX system engineer MSCE
Re: Keeping an handle on client systems' large drives
Wanda, I agree, but backing up everything just because it is there is a very expensive issue. In most companies, IT in one form or another is 'charged back' to a client department, but to keep down spending on IT, the decision is made, either by IT or the client department management, to not backup everything. TSM is the only backup solution I have run across that does not re-backup things that have not changed, and this is why I support it in deference to other backup solutions whenever possible. As I have told clients I consult for, and both management and internal clients I have worked for, is we can back up everything, you just have to pay for it. And when the price tag comes out, they don't like the answer. The compromise is not normally between IT and the end clients, it is between the client and the budget. IT just gets stuck in the middle. Other options are: 1. Use a central terminal server and thin client desktops that do not have or need disks on the desktop. (Sun has/had a Cashing file system that worked great, Wise sells Winterm terminals that use a central terminal server, there is also the Linux Terminal Server Project to do this with open source software. It is possible, it works, but lots of folks don't like it for their own reasons) 2. I have had some clients where their answer to backups is to not backup. They put everything on RAID5 systems or mirrors, automate the checking on these systems and don't worry about it. (I do not condone this behavior, I have just observed it.) 3. Use an operating system that keeps data backed up. I only know of one, and it is not considered an option by most companies. Check out ATT/Lucent/Bell Labs OS called Plan9 (http://cm.bell-labs.com/plan9dist/). It has an interesting method where when you change a file, it is effectively backed up. And to retrieve it, just do a change directory to last Tuesday at 3PM if you want to. ... Interesting in concept, but probably not practical for most of our institutions. BTW, they migrated, like HSM, off to optical media. I guess we could emulate this if we had a big HSM system that was used instead of large disk farms. But Plan9 was DESIGNED with backup as part of its architecture from what I can tell. It was not retrofitted like every other OS I have seen (including NT, IBM's VM, *NIX(in all its flavors), MVS, MVT, IBM's mainframe DOS, CRONOS, and others). A Backup Story: Once upon a time I worked for a large oil company supporting their exploration department as a unix desktop admin. We purchased some 9G disk drives (huge in their day) for a few high dollar exploration geophysicists. We also installed an tape drive on each of these peoples desktop, with instructions on how to use it, and who to call if there was a problem, or if they needed tapes, or handholding, etc. The drives were pretty reliable. But we still suggested users put a tape in at the end of the day and we (as the admins) would provide a script to run on their Sun workstations to tar their files off to tape. As is normal, users ignore their admins (as we ignore our doctors advice about eating and drinking sensibly) and a disk died. We replaced the disk, then asked the user for their backup tapes, as we were glad to restore the data for the user. The most recent backup was 6 months old. This $100K/year user almost got fired over this, as it contained ALL his previous 6 months of effort. We did get back about 60% of his data, with a $20K recovery fee from a data recovery company. WHY this story? He saved the company millions of dollars in data. Because it scared the rest of our user community into asking 'how do I back up my data?' or 'do you have a tape I could use to backup my data?' etc. It was just an expensive way to get there. We did do central backups of all computer room based data, databases, etc. But not the desktops. Why? There was no maintenance window we could have agreement on to backup the desktops, and if we did, there was insufficient bandwidth to centrally back them up. Another story of it could be done, but we were told it was not worth the $$$ money. ... Time to go change a tape ... Jack -Original Message- From: Prather, Wanda [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 10:11 AM To: [EMAIL PROTECTED] Subject: Re: Keeping an handle on client systems' large drives This is always a trade off between what is practical-possible-available-affordable and the backup coverage you need. But I would like to put in a word AGAINST the if they don't save it in the right place they don't get it backed up philosophy. I'm not criticizing you guys specifically here, this is just MY point of view on one backup philosophy issue that resurfaces continually here on the list. Partial backups + user rules has always been the accepted solution for IT support, because backing up everything in the environment
Re: Keeping an handle on client systems' large drives
*.gho are image files produced by the Ghost program from Symantec. I think *.nrg files are something to do with CD burning programs, something like an *.iso file. *.rm is an audio/video file from RealAudio -Original Message- From: Prather, Wanda [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 11:13 AM To: [EMAIL PROTECTED] Subject: Re: Keeping an handle on client systems' large drives Mark, I know about mp3s and we do exclude them; what are : .nrg, .wmf, .rm, and .gho? -Original Message- From: Mark Stapleton [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 8:24 AM To: [EMAIL PROTECTED] Subject: Re: Keeping an handle on client systems' large drives From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Foster Not every site is lucky enough to be able to convince the beancounters the merits of having a backup system that keeps up with the needs of the end users, even if it means one has to explain doomsday predictions on the business bottom line -- they invariably hear that then say Oh, pshaw, you're just exaggerating because you want money It sucks to be the one that's right ;) And the ones who warns well before a nasty event occurs may also be the first one to be fired out of spite after something happens and gets the blame for not having prevented it. There is only one thing that will convince the beancounters that backup resources must be kept to adequate levels: one bad day Put your objections in email, send that email to those who matter, and *keep* *a* *copy*. Gently (but regularly) remind the powers-that-be that your backup resources are inadequate. In the meantime, aggressively filter what is being backed up. An increasingly large amount of data is going to files with extensions like .nrg, .wmf, .mp3, .rm, and .gho (my current unfavorite). Don't back 'em up. -- Mark Stapleton ([EMAIL PROTECTED]) Certified TSM consultant Certified AIX system engineer MSCE
Keeping an handle on client systems' large drives
I've always been curious about something. How do you keep an handle on the fact that commodity PC storage is growing at a far faster rate than tape capacity/system is? For example, if I had a small LAN of about 300 PCs -- let's say, an academic or corporate departmental LAN environment... each has at least a 40 GB HD, and probably a fair amount of apps and files on them. In the stores, I see drives up to 160 GB, with even larger ones on the way! So let's say, an average of 25 GB utilization per system... a single full backup would be about 7.5 TB, which is quite a few tapes ;) Not everybody is using LTO or higher capacity. So do those sites rely purely on the incrementals to save you? Or some site specific policy such as tailoring backups to exclude (let's say) C:\Program Files, or some such...? Just wondering. Not every site is lucky enough to be able to convince the beancounters the merits of having a backup system that keeps up with the needs of the end users, even if it means one has to explain doomsday predictions on the business bottom line -- they invariably hear that then say Oh, pshaw, you're just exaggerating because you want money It sucks to be the one that's right ;) And the ones who warns well before a nasty event occurs may also be the first one to be fired out of spite after something happens and gets the blame for not having prevented it. -Dan Foster IP Systems Engineering (IPSE) Global Crossing Telecommunications
Re: Keeping an handle on client systems' large drives
Actually, Dan, sorry for my remark. What you have to do is revisit what you are saving and put in exclude.dirs for all directories that contain software that can be rebuilt from a common desktop image (hard drive replacment). Have your users save their documents in specific folders and only back them up. Then they just have to customize their desktop configure their node name in the dsm.opt and restore the stuff that is backed up. This is the trade-off. The other approach is the backupset that is a CD sent to them and incremental restore from that point forward. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Dan Foster [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: Keeping an handle on client systems' large drives I've always been curious about something. How do you keep an handle on the fact that commodity PC storage is growing at a far faster rate than tape capacity/system is? For example, if I had a small LAN of about 300 PCs -- let's say, an academic or corporate departmental LAN environment... each has at least a 40 GB HD, and probably a fair amount of apps and files on them. In the stores, I see drives up to 160 GB, with even larger ones on the way! So let's say, an average of 25 GB utilization per system... a single full backup would be about 7.5 TB, which is quite a few tapes ;) Not everybody is using LTO or higher capacity. So do those sites rely purely on the incrementals to save you? Or some site specific policy such as tailoring backups to exclude (let's say) C:\Program Files, or some such...? Just wondering. Not every site is lucky enough to be able to convince the beancounters the merits of having a backup system that keeps up with the needs of the end users, even if it means one has to explain doomsday predictions on the business bottom line -- they invariably hear that then say Oh, pshaw, you're just exaggerating because you want money It sucks to be the one that's right ;) And the ones who warns well before a nasty event occurs may also be the first one to be fired out of spite after something happens and gets the blame for not having prevented it. -Dan Foster IP Systems Engineering (IPSE) Global Crossing Telecommunications
Re: Keeping an handle on client systems' large drives
Ask them where they were on 9-11-2001. Are they totally brain dead? Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -Original Message- From: Dan Foster [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: Keeping an handle on client systems' large drives I've always been curious about something. How do you keep an handle on the fact that commodity PC storage is growing at a far faster rate than tape capacity/system is? For example, if I had a small LAN of about 300 PCs -- let's say, an academic or corporate departmental LAN environment... each has at least a 40 GB HD, and probably a fair amount of apps and files on them. In the stores, I see drives up to 160 GB, with even larger ones on the way! So let's say, an average of 25 GB utilization per system... a single full backup would be about 7.5 TB, which is quite a few tapes ;) Not everybody is using LTO or higher capacity. So do those sites rely purely on the incrementals to save you? Or some site specific policy such as tailoring backups to exclude (let's say) C:\Program Files, or some such...? Just wondering. Not every site is lucky enough to be able to convince the beancounters the merits of having a backup system that keeps up with the needs of the end users, even if it means one has to explain doomsday predictions on the business bottom line -- they invariably hear that then say Oh, pshaw, you're just exaggerating because you want money It sucks to be the one that's right ;) And the ones who warns well before a nasty event occurs may also be the first one to be fired out of spite after something happens and gets the blame for not having prevented it. -Dan Foster IP Systems Engineering (IPSE) Global Crossing Telecommunications
Re: Keeping an handle on client systems' large drives
Hot Diggety! Seay, Paul was rumored to have written: What you have to do is revisit what you are saving and put in exclude.dirs for all directories that contain software that can be rebuilt from a common desktop image (hard drive replacment). Have your users save their documents in specific folders and only back them up. Then they just have to customize their desktop configure their node name in the dsm.opt and restore the stuff that is backed up. This is the trade-off. Makes sense. Basic education + cost saving vs expense from a brute force approach. The trick is to have education that works well for a wide range of users, with differing expertise, and to also clearly communicate expectations (if you save anywhere else, you won't get it back!). Now that sounds like I also have to train them to not just blindly click whenever an application offers them a default directory (often within app area) to store documents in. Perhaps a small data area carved out on the hard drive, like say, 5 GB partition for user documents as Z: or whatever, and similiarly for other platforms (/userdocs/user as a symlink from ~user/docs or whatever), to provide a consistent and easy-to-use area for end user, yet predictable area for mass-deployed *SM configurations to use. I'm sure that the IT shop can help out significantly if they're able to preconfigure these settings within each application before users gets their hands on the machine. Hard part is when not every place has that luxury, especially at smaller places where end users may be configuring everything on their own. Anyway, the overall education/training approach is definitely cheaper than having to save everything on the HD, I do agree. ;) -Dan Foster IP Systems Engineering (IPSE) Global Crossing Telecommunications
