I try to forget, but that doesn't work. I was at the offsite operation twice, one a very long weekend. IME they never go smoothly, mostly because of different hardware. (Sysprep anyone?) This was all mainframe, and getting the OS and data management up always led to long delays. In the end though, even if all apps didn't get running properly, there was always enough up and running to call it a "success."
hehe.
When you've seen how others have experienced data loss, and you already know how fragile the hardware and software is, it really becomes impossible to disregard.
One would hope they know when to call it "quits". If they actually experience a disaster and they're willing to live with the extra work they know it'll take to do the complete recovery, I guess you have to leave it up to them to live with any consequences.
I think my problem is I strive for perfection, even though I know I could easily manage otherwise if disaster actually hit.
Very good thread! Many readers (including myself) can derive some benefit from it.
I was on the application end, and paid little attention to the IBM model or OS version after the 370, but I doubt the recoveries I participated in were VM sessions. More likely the problems were natural to such a massive task, because it was a very large company with many interfacing applications. I specifically remember unexpectedly being called into one (they normally only used staff, and I was a contractor) when essential VSAM files couldn't be loaded. It's cloudy now, but it may have been the define clusters were erroring. After some time I managed to load them with a workaround, but there was obviously a difference in the off-site OS VSAM parameters that didn't exist at the home office OS. It may or may not have related to the disk drives used off-site. Really not much different from some problems you see on this forum.
To F5ing, "knowing when to quit" is exactly right.
Large company disaster recovery exercises are very expensive, and take a toll on staff, subtracting a weekend from their lives. I saw one where some staff were still off-site on Monday, and that affects the work week business operations.
I do believe that those I mentioned can be called "successful" because what didn't work was identified, and a solution for the future found and locked in.
Realistically, those in charge of disaster recovery have no illusions about it, and give upper management a sober assessment of how long it will take to get the enterprise up and running again - barring what Murphy has to say about it.
Hi,
I have another question - I am about to move my pictures to drive D, but I still want to have a shortcut to my pictures on my desktop. When I image my drive C using Macrium, will it pull in my pictures.....?
You understand that my objective here is not to pull my pictures in while imaging drive C.
Thanks,
BBDS
I'm not sure about Macrium, but imaging/cloning apps typically will copy/image/clone only the data within a partition/disk. They will copy the shortcuts, links, etc. if they are in the partition/disk, but will not follow them to also copy the data they link to.
Sounds like you're really catching on, as that's pretty much the idea. You want access to the data for normal use regardless of where it's located, so you link it or add it to a library for ease of access.
You're welcome! Good luck with setting up your new strategy. You'll get the hang of it pretty quickly.
One more question, if this is not too much....
I created a repair/boot cd for my W7, but is there any easy way to do the same for XP....?
Thanks,
BBDS.
Quote