said:
>I'm okay with the backups. I make daily backups, and I keep my OS2*.INI
>and CONFIG.SYS files "forever". I also keep two backup generations of my
>Desktop\ directory. And I also keep "forever" the OS2*SV.INI files which
>CheckIni creates.
As I've mentioned before, this is insufficient to guarantee a working
restore.
>And some people use RoboSave, and I use xcopy.
I recall a guy whining that his xcopied backup did not work when he tried
to use it to restore. I explained what he did wrong and suggested he was
going to have to do a full reinstall.
>I rely on my daily backups for restorations, though I realize I don't
>have the generation depth that these specialized programs give you. But
>I do keep the OS2*.INI files from the backups "forever".
It's not so much the depth as knowing the state of the system at the time
the backup was made. One of the first things I convinced Jim Read to do
when he took over Unimaint was to add the backup description option. Now
I know which backups correspond to important events and which supplemental
backups correspond to the WPS backups.
>Yes, good advice, it's important to *not* boot to the Workplace Shell on
>the drive that you're trying to restore to. I have a separate
>Maintenance partition (F:) which I boot to.
Same here. Very handy for installed FP's and any other operations that
work better if there are no locked files. FWIW, my maintenance partitions
are just a data partitions that have minimal BOOTOS2 setups. This
requires about 3MB per drive, which is nothing these days.
>(Lurkers: The Workplace Shell reads the OS2*.INI files into memory and
>uses the memory copy, not the files on the disk. When you shut down it
>writes the memory contents back to the disk. If you restore the disk
>files with the WPS running, the restoration will be overwritten when you
>shut down. Of course, you could just power off . . .)
This is not true. The WPS caches the active data in memory. A worker
thread writes most modifications to disk as time permits. If this were
not true, a CAD would always lose all WPS modifications. Unlike a desktop
shutdown, a CAD reboot does not notify applications that a shutdown has
been requested.
For some reason, the WPS does not write location changes for the Desktop
folder to disk until a Desktop shutdown. If you reposition an object on
the Desktop and CAD reboot, it will return to its prior position. This
might be by design as a way to recover from an unintended RMB -> Sort or
RMB -> Arrange on the Desktop. I really don't know.
>Yeah, sometimes I've had to walk backwards three or four generations
>until I found a good one.
The reasons for this are pretty obvious. GIGO and you only back up half
of the required data.
>Question: Why should UniMaint, CheckIni and CleanIni be run in that
>particular order?
Experience shows this provides maximal results in minimal time. Frankly,
I only run Checkini and Cleanini once every other month or so. A
bi-weekly Unimaint run is good enough for my boxes. I typically do a
Unimaint backup after I install new applications. I might skip it for
simple apps that just create Desktop objects, I might even skip the
backup. For large applications, like Smartsuite which install lots of
objects and classes, I will backup before the install, just in case.
However, my experience has been that if you handle the WPS with reasonable
care, given working hardware, the number of times you will need to restore
it will be very small. Just doing backups is not sufficient. You need to
understand why you are backing up the chosen data.
>CleanIni appears to be the program that zapped the most stuff, and might
>have caused my current problem (the UNIMAINT folder freezes my system).
Hard to say. All I can say, is before I ran it live the first time, I
made sure I understood what it was going to do and how I would recover if
it screwed up. Note that this box has not been reinstalled since. 2/28/97
so cleanini found lots of work to do even though unimaint and checkini
reported no errors. I didn't keep notes, but I'm pretty sure it took well
over a dozen passes before it stopped finding items to delete. I just ran
cleanini to get a count. I'm up to a 100 delete candidates again because
this box is pretty active.
>Perhaps CleanIni sometimes removes stuff that shouldn't be removed?
Anything is possible, but this is not appear to have happened to others.
>line processing, and I probably have a lot of INI entries for files that
>have been moved, renamed or deleted from the command line. I even rename
>directories on-the-fly -- it's part of my daily processing procedure.
This is all fine. I do it too. Checkini finds the dead references and
deletes them. There's something else going on.
Steven
--
----------------------------------------------------------------
"Steven Levine" MR2/ICE 2.29d #10183 Warp4/FP11.5
www.scoug.com irc.webbnet.org #scoug (Wed 7pm PST)
----------------------------------------------------------------
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 08 |
September |
2001 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
