Backup and Restore
Kil...@someisp.gov
Win2K, oh fellow stick-in-the-muds?
Over the years I've had a couple of HD failures, one under Win3.1
(restore from floppies), one under NT (re-install OS), and the latest
a couple of years ago when I had PATA drives and a Ghost backup. Now
my version of Ghost doesn't work with SATA drives, nor with large HD's
(equally Partition Magic doesn't do it above 300 gig). So what I've
been using is a combination of Windows Backup for ERD, System State,
and the C drive; and Windows Copy and Paste for the D, E, and F
drives. But I'm becoming increasingly nervous about this practice
especially when I read (and re-read) the Help files on Windows Backup.
Nowhere do they address the issue of a completely dead boot drive
which has to be restored from the backup. They seem to think that you
have the ability to re-install Windows from the original disks. Well I
can but then there's the upgrades and the slipstreaming of the SATA
drivers (which are no longer supported by Intel but work) and SP5 and
the problem of LBA, and... it goes on and on.
I also have my backup drive in the same box as the live data and I've
been reading about people who had an electrical surge which fried
their entire system. Hey, if the house burns down, I can live with
starting life again, but if everything else is OK but the
PC...well...I could get really aggravated.
So, bear with me while I explain the relevant parts of my setup:
Floppy
CD/DVD writer
WD Caviar 1TB (live data)
WD Caviar 1TB (backup)
The two Caviars are exactly the same (C,D,E,F map to G,H,I,J
respectively). The C drive is Win2K plus a very small amount of data
(for example: the Agent data files), D is all the other software as
far as I'm given the option (the SATA drivers have to be on C), E is
around 450 gig and is 140 gig used (mainly photos) and F is also
around 450 gig and is 350 gig used (mainly movies).
G contains two iterations of Windows Backup of C and two iterations of
System State. H has two iterations of Copy and Paste of all the files
on D except Recycler, System Volume Information, and similar. I has
two Copy and Paste iterations of E with the same exceptions as D/H and
finally (and the problem) J has only one iteration of F (same
exceptions) due to the original size.
Where's that little thing called the MBR? Who knows? But presuming I
can find some method of creating a file somewhere called (say)
MBRbackup I still have to find some way of writing it in the correct
manner and position to my new blank 1 TB Caviar I would buy to rebuild
the system.
Another problem is with my lack of understanding (and perhaps the
non-understanding of others) of this question of placement of files in
C. If I take the contents of C and copy it to (say) a DVD and then
copy back those files to a blank Caviar some say they won't work. IOW
they assert that some (undefined) O/S files must be an exact physical
location (not talking about an MBR) like Track 5971 Sector 6878.
Others say b/s! O/S files are just files like any other files except
that they must be in a specific directory (WinNT for example), and
must be within the first n-gig of the C drive (n is a number like 2
and this is because of early disk geometry). My experience and reading
incline me to the conclusion that the specific track/sector is b/s by
self-important system programmer types. Anyone really know?
If we can get over the MBR copy and the C placement question I still
have a problem: You have no idea how long those Copy and Paste
operations take. Actually it's not only C&P it's the Delete up front
too and to add insult it's also the "Preparing to Delete" and later
the "Preparing to Copy". It's not "Go have a cup of coffee" it's "Go
have lunch, take the dog to the vet, visit Home Depot" and when you
return it's still not finished. Sheesh!
I seem to remember a program under MS-DOS that would copy only new and
changed files and (this is the important part) remove files not
present on the original. I thought this was XCopy but the business of
removing/deleting old non-current files doesn't appear in the help
description. Think about it: Most of the files on F (and hence J) are
huge and never change so they don't need to be recopied every time.
For most there's never a change internally; the only thing is that
they can be deleted, and of course there could be new files. If I
could get a program to just do this (reliably) it would be an enormous
help.
Which brings up some things I don't even want to think about: as far
as possible I want to have backup in normal NTFS format. Separate
files that can be copied on any OS that supports NTFS. No proprietary
formats. No sector by sector copies. No cloning. And I don't even want
to hear about RAID, spanned, layered, or other super-sophisticated
formats. Like electric windows on cars they're just another thing to
go wrong.
I have this vague recollection that WD's Data Lifeguard Tools (DLT)
will create partitions on a new drive (they have something like the
old fdisk) and by implication they will also create an MBR. So maybe
one doesn't even need to back up the MBR? Of course WD has changed to
their proprietary version of Acronis which doesn't support ... guess
which O/S. Assholes! But fortunately I have several CD's of DLT from
earlier versions. Do they support SATA? I think so but I don't want to
try and they say they won't let me do it anyway if there is a boot
partition already on the system.
Then there's the question of the moving target of copying (or even
Windows Backup[ing]) of the C drive. Or will this really matter? I'm
sure there's multi log files open at the time but even if they're not
copied won't Windows rebuild them if it can't find them at boot?
Tell me what you think. Please no "Upgrade to the latest Win 7/8" or
change to one of the versions of Unix. Eventually I (and probably we)
will have to relent and upgrade. Personally I'm thinking of a cracked
Russian version but the malware problem worries me.
Steven Saunderson
> I seem to remember a program under MS-DOS that would copy only new and
> changed files and (this is the important part) remove files not
> present on the original.
I use a Win32 console mode program called Save32.exe that has options to
do what you want:
/a = add (copy if not backed up)
/u = update (copy if source newer than target)
/s = process sub-directories
/b = backdate (copy if source older than target)
/r = delete source if not backed up
If I wanted to backup drive C to G I'd use: Save32 c:\*.* g: /a/s/u
To remove files on G but not C I'd use: Save32 g:\*.* c: /r/s
Save32 copies the file dates but not attributes. It will not overwrite
any file with read-only, hidden, or system attributes set.
The URL for the exe is <http://phelum.net/files/Save32.exe> .
The URL for the source is <http://phelum.net/files/Save32.cpp> .
If you do try it, I'd recommend backing up a single directory first just
to make sure it does exactly what you want.
When backing up try to use the same filesystem (e.g. NTFS to NTFS).
NTFS to FAT32 (or vice-versa) causes a problem when summertime starts or
ends because the file dates on NTFS volumes change by one hour because
NTFS records UTC timestamps.
Some OS files can't be backed up (access denied). To overcome this I
have a dual-boot system where I run my primary OS and back up the
secondary then run the secondary and backup the primary.
Hope this helps,
--
Steven
Skywise
4ax.com:
> What suggestions do you have for backing up and restoring the HD's in
> Win2K, oh fellow stick-in-the-muds?
Here's what I do. It may take some time and money to get set up
like this. May not be directly helpful to your current setup, but
might give you food for thought on a direction to go.
I always buy drives in pairs. That way I have at least two identical
drives, save for serial numbers (which comes in handy telling them
apart). The idea is that one is used, the twin is it's backup. Makes
cloning easy since it guarantees the drives are compatible.
I have all my drives in removable drive bays. Makes it easier to
swap drives and put in/take out the backup drives. Yeah, I gotta
shut down and reboot, but it's a small price to pay for saving data.
I suppose you could get by with just the backups being removable.
For non-system drives/partitions, I simply click & drag to copy
files to the backup. Actually, in this case it's not necessary to
have identical drives, just enough space. As I dabble in programming,
I made myself a little utility that compares entire directory trees.
This is useful to see what's new to put on the backup, and also
verify's the contents to the byte to make sure I have valid copies.
I'm planning to expand it to automate this process. Unfortunately
the way it's written it's not fit for public consumption. It was
orignally written to verify CD burns back in the day when coasters
were common.
But, for the system drive I have some software (whatever works for
you) that allows me to make a clone. Doesn't need to be anything
fancy as all it's doing is copying bits. A clone is great as you
don't need to 'restore' anything. Just pull the bad drive and put
in the clone. It'll boot like the original.
I have multiple computers. When I need to clone the system drive, I
can put the drive and its backup in another computer and perform
the task there.
Alternatively, as I have upgraded to larger disks over the years,
I set aside one of the smaller ones and put a minimal OS (win2k!!!)
and utility software on it. This is my emergency system, and also
contains a copy of the cloning software.
The next part is discipline. Remembering to back up often enough.
BTW, in all my life I've only ever lost two HD's. The first was about
14 years ago (only 212meg) and the 2nd a couple months ago. My systems
are on 24/7/365.
Hope this is useful.
Brian
--
http://www.skywise711.com - Lasers, Seismology, Astronomy, Skepticism
Sed quis custodiet ipsos Custodes?
Java Jive
> What suggestions do you have for backing up and restoring the HD's in
> Win2K, oh fellow stick-in-the-muds?
==========
There are four major ways, and doubtless countless variants which I
shall ignore, of backing up PCs:
1) File-by-file copy to an external drive eSATA or USB drive, another
PC, a NAS server, etc, using native OS functionality such as Explorer,
XCOPY, and the WinDiff program from the OS support tools on the CD.
+ Individual files can easily be backed up to and restored from
the destination.
+ Can be done from within the normal OS, no need for an
alternative OS to run the backup. BUT ...
- This cuts both ways, for that very reason it isn't suitable
for backing up the OS itself, as many of its critical files will be
locked in use.
- There is scope for handling generations of file versions but
you have to make all the effort, so this would probably not be
suitable for work such as program development where sometimes it might
be necessary to revert to a file version some generations before the
current one. Really, you would need a proper versioning system for
something like that.
- Not good for small amounts of changed files buried deep in
large quantities of data stored in complex directory structures.
In summary, reasonable for small quantities, probably at most a few
GB, of personal data which is mostly non-professional in nature.
2) File-by-file copy to an external drive eSATA or USB drive, another
PC, a NAS server, etc, using a program like DeltaCopy.
Much as 1, except ...
+ Because only changed files are copied, it copes much better
with small amounts of changed data buried within larger amounts.
! Those such program that are based on Linux rsync
functionality, like DeltaCopy, may have problems with file
permissions, attributes, and names containing accented characters.
However, as, IIRC, the original rsync can be used with versioning
systems, then probably these program also can be, though I have no
practical experience of this.
In summary, good for large quantities of data, particularly personal
data.
3) Using a bespoke Backup program such as that supplied with Windows.
Such programs commonly copy the data into an archive file, possibly
spread over several media such as HD, DAT, CD, DVD, etc.
+ Can be good for corporate systems using automated procedures
on a nightly basis, etc, but such 'professional' systems are usually
prohibitively expensive for a private user.
+ Such a program will probably cope better with backing up OS
system files, BUT ...
- May or may not backup essential parts of the operating system
such as boot-sectors.
- May use a proprietary archive format not readable by other
software, even other backup software, but even if it doesn't, ...
- Restoring an individual file can be time-consuming and
awkward.
- It may be that if a single media in a set is unreadable, then
the whole backup set is lost - surprising as it sounds, not to say
horrifying as it was to me, I encountered this with an expensive,
apparently 'professional' system.
In summary, good for corporate systems backing up huge quantities of
data, but probably not for the home user.
4) Imaging a disk or partition using a program like Ghost. Again,
the entire disk or partition is copied into an archive file, which may
or may not span several files or media, but this time by a program
running under a different or restricted operating system.
Much as 3, except ...
+ Will backup an entire operating system, including essential
boot components such as the MBR containing the partition table,
dual-boot configuration data, and the PBR, and there will be no
problems with locked files.
- Some imaging programs behave like malware in that they write
signature data to unused sectors of the disk, seemingly to track
licensing or copy protection in some way. For example Ghost writes to
sector 62.
- Professional imaging systems such as Ghost can be expensive.
- Because of the necessity of running the imaging program under
an alternative OS - W9x running in DOS console mode is commonly used
- there may be problems obtaining DOS drivers for modern hardware,
particularly modern netcards.
Particularly good for system disks.
==========
In summary, what works well for data doesn't work so well for the OS,
and vice versa. For this reason, I have long advised divided the two
into seperate partitions or disks, and backing up data frequently
using 1 or 2, and periodically the system disk or partition using 3 or
4.
There are many other advantages to doing this, for example, if you
wish to try an alternative OS, you can backup the existing system disk
using 3 or 4 above, install the new OS, then, if you find it doesn't
answer, restore the original OS. All this theoretically without
endangering your data, though I'd always backup the data using 1 or 2
as well as the system disk using 3 or 4 before making such major
changes to a PC - it's easy to get muddled in Ghost and setup
programs where the familiar disk designations and labels may not be
there to guide one, and so overwrite the wrong disk or partition.
As you are not intending to create multiple copies of the same OS to
put on different hardware, much of this link will be overkill for you
- skim those bits quickly - but I suggest you read about dividing
the data from the programs and OS:
http://www.macfh.co.uk/JavaJive/Windows/WindowsImageBuilding.html
> Now
> my version of Ghost doesn't work with SATA drives, nor with large HD's
> (equally Partition Magic doesn't do it above 300 gig).
[snip]
> the slipstreaming of the SATA
> drivers (which are no longer supported by Intel but work) and SP5 and
> the problem of LBA, and... it goes on and on.
What version of Ghost are you using? I have had few problems with
v2003, and none that I recall with SATA or even SCSI disks. My
biggest problem recently has been finding DOS/W9x drivers for recent
network cards, and both DOS/W9x and Ghost object to having 4GB RAM in
the PC. I have to remove a stick of RAM before backing up the system
disk.
> I also have my backup drive in the same box as the live data and I've
> been reading about people who had an electrical surge which fried
> their entire system.
Or perhaps more likely if the computer is stolen ... Either way, where
would you be? At least use an external disk you lock away in a drawer
or some such place.
> So, bear with me while I explain the relevant parts of my setup:
>
> Floppy
> CD/DVD writer
> WD Caviar 1TB (live data)
> WD Caviar 1TB (backup)
>
> The two Caviars are exactly the same (C,D,E,F map to G,H,I,J
> respectively). The C drive is Win2K plus a very small amount of data
> (for example: the Agent data files)
Copy agent's data to the data drive and then alter the program Start
Menu shortcut(s) to
"C:\Program Files\Agent\agent.exe" "<path>"
... for example ...
"C:\Program Files\Agent\agent.exe" "D:\Agent"
... and similarly set the Start In folder in the shortcut.
> D is all the other software as
> far as I'm given the option (the SATA drivers have to be on C), E is
> around 450 gig and is 140 gig used (mainly photos) and F is also
> around 450 gig and is 350 gig used (mainly movies).
Seems overkill to me. All that is really needed is OS/software on one
partition and data on another. Further partitioning just wastes hard
disk space.
> G contains two iterations of Windows Backup of C and two iterations of
> System State. H has two iterations of Copy and Paste of all the files
> on D except Recycler, System Volume Information, and similar. I has
> two Copy and Paste iterations of E with the same exceptions as D/H and
> finally (and the problem) J has only one iteration of F (same
> exceptions) due to the original size.
You could use an rsync clone such as DeltaCopy to keep the data in
sync.
> Where's that little thing called the MBR? [snip] Another problem is
> with my lack of understanding [snip] Anyone really know?
In order to understand what follows you will need to understand how a
PC boots into an OS stored on a hard disk. I've described the process
here:
http://www.macfh.co.uk/JavaJive/PCHardware/PCBootProcess/PCBootProcess.html
Basically it's:
BIOS
-> MBR of HD selected in BIOS Setting/BIOS Boot Menu
-> PBR of 1st 'Active' partition found on that disk
-> OS in that partition loads as further described below ...
Before going further, two important points to grasp:
A) A disk's MBR contains the master boot loader AND the partition
table and other disk-related meta data.
B) A partition's PBR contains the OS-specific partition boot loader
AND other partition-related meta data.
Now I'll describe the OS-specific parts of the boot as they apply to
Windows:
DOS and Windows up to and including W9x (IBM's and DRDOS's
arrangements were similar, but sometimes used different filenames):
i) The PBR loader code examines only the very first file entry in the
root directory, which MUST be for the file IO.SYS, loads that file,
and jumps to a routine in this file to continue the boot.
ii) The loader in IO.SYS examines the second file entry in the root,
which must be for the file MSDOS.SYS, loads that file, and jumps to a
routine in this file to continue the boot.
iii) This final chained routine initialises and configures the OS,
processing CONFIG.SYS, loads the command-line interpreter COMMAND.COM,
and passes control to it.
iv) COMMAND.COM runs any batch commands found in AUTOEXEC.BAT
In summary:
PBR -> IO.SYS -> MSDOS.SYS -> COMMAND.COM
Originally, as their names implied, IO.SYS contained all the IO
routines, and MSDOS.SYS the higher OS functionality. However, for
W9x, all the OS is contained in IO.SYS, and MSDOS.SYS is just a text
configuration file which is processed just before CONFIG.SYS.
To make a disk bootable, you either give the command
FORMAT /S <drive>
... or ...
SYS <drive>
Both these commands overwrite part of the PBR with a suitable
partition boot loader, and copied the three files required into the
root directory, ensuring that the first two held the first two entries
as required, any preexisting file entries being pushed down to make
room for them.
W2K and XP:
The partition boot loader in the PBR looks for the file NTLDR in the
root directory (there is no longer a requirement for it to be the
first entry in the root). NTLDR parses the BOOT.INI file, if any, and
loads the chosen OS. NTDETECT.COM is also required, it checks the
PC's hardware configuration.
IMPORTANT!
The two OSs have different versions of NTLDR, and by default XP's will
not load W2k.
After OS installation proper and from within the running OS, the
Recovery Console can be installed as a boot option by giving the
command
<CD Drive>\I386\WINNT32.EXE /CMDCONS
It is instructive to discover how this works, because it partly
answers some of the uncertainties that you raise, mirrors how Windows
Setup configures Windows itself to boot, and is strongly analogous
with dual-booting with earlier MS OSs.
The current (2K/XP) PBR is copied into the file ...
\CMDCONS\BOOTSECT.DAT
... and this file's loader is then further adapted it to call ...
\CMLDR
... instead of ...
\NTLDR
Note: This description suggests that the resulting BOOTSECT.DAT file
should be 1 sector = 512 = 0x200 bytes long, but in fact due to the
adaptation to load the RC it is longer.
Finally an entry is added to BOOT.INI to call the loader in
BOOTSECT.DAT as though it were still an actual PBR:
<boot drive>\CMDCONS\BOOTSECT.DAT="<description>" /cmdcons
IMPORTANT!
Just like Windows Setup proper, RC installs onto and adapts the
CURRENTLY ACTIVE PARTITION ON THE DRIVE THAT WINDOWS WAS JUST BOOTED
FROM. In dual-boot systems, this may not be the 2K/XP drive or
partition.
IMPORTANT!
Because the PBR, and therefore BOOTSECT.DAT, contains partition meta
data along with the loader, EVERY VERSION OF BOOTSECT.DAT IS UNIQUE to
the partition in which 2K/XP is installed. If the file is lost, it
can only reinstated by re-installing the RC, NOT just by copying in a
version from another computer (unless perhaps the HDs and their
partitioning happen to be completely identical). Also, if you examine
the dates of other files in \CMDCONS, there are usually a couple of
others that date from the time of the RC installation. I'm not clear
how necessary these are for the correct functioning of the RC once you
are in it, presumably they are, but only BOOTSECT.DAT appears to be
important for actually booting into it.
(Vista, as I presume, and) W7:
I've never used the former, and am still relatively new to the latter,
but I think what happens is ... The loader in the PBR looks for the
file \BOOTMGR, which then parses the boot configuration database in
the \BOOT folder and displays the boot menu. If an earlier version of
Windows is selected from the menu, then NTLDR is called, otherwise
Vista/W7 is booted in its normal way.
> If we can get over the MBR copy and the C placement question I still
> have a problem: You have no idea how long those Copy and Paste
> operations take. Actually it's not only C&P it's the Delete up front
> too and to add insult it's also the "Preparing to Delete" and later
> the "Preparing to Copy". It's not "Go have a cup of coffee" it's "Go
> have lunch, take the dog to the vet, visit Home Depot" and when you
> return it's still not finished. Sheesh!
See Option 2 above.
> I seem to remember a program under MS-DOS that would copy only new and
> changed files and (this is the important part) remove files not
> present on the original. I thought this was XCopy but the business of
> removing/deleting old non-current files doesn't appear in the help
> description. Think about it: Most of the files on F (and hence J) are
> huge and never change so they don't need to be recopied every time.
> For most there's never a change internally; the only thing is that
> they can be deleted, and of course there could be new files. If I
> could get a program to just do this (reliably) it would be an enormous
> help.
AIUI, the best that XCOPY can do is only copy files that have the A
attribute set, clearing the attribute as it does so. Windows
automatically sets this attribute on every file that is modified.
XCOPY won't delete on the backup destination files that were deleted
on the original source, you need a sync program to do that.
See the preliminary discussion for your other points.
> Tell me what you think. Please no "Upgrade to the latest Win 7/8" or
> change to one of the versions of Unix.
I suspect I may move to Linux for most things eventually, but right
now I have no time discover the Linux alternatives for the many
Windows programs I know and love, or at least love to hate.
> Eventually I (and probably we)
> will have to relent and upgrade. Personally I'm thinking of a cracked
> Russian version but the malware problem worries me.
Bad idea.
--
=========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html
Seum
available. All you have to do is to go to the right place and do a
backup - you have to specify where the backup has to be saved. Kid
stuff! :-)
> .... for example ...
>
> "C:\Program Files\Agent\agent.exe" "D:\Agent"
>
> .... and similarly set the Start In folder in the shortcut.
> .... or ...
> .... and this file's loader is then further adapted it to call ...
> \CMLDR
> .... instead of ...
Java Jive
>
> I used Win2K for years and years and it has its own backup program
> available. All you have to do is to go to the right place and do a
> backup - you have to specify where the backup has to be saved. Kid
> stuff! :-)
I am very well aware of that. However, you do not seem to be aware
that ...
> > 3) Using a bespoke Backup program such as that supplied with Windows.
> > Such programs commonly copy the data into an archive file, possibly
> > spread over several media such as HD, DAT, CD, DVD, etc.
> >
> > + Can be good for corporate systems using automated procedures
> > on a nightly basis, etc, but such 'professional' systems are usually
> > prohibitively expensive for a private user.
> >
> > + Such a program will probably cope better with backing up OS
> > system files, BUT ...
> >
> > - May or may not backup essential parts of the operating system
> > such as boot-sectors.
> >
> > - May use a proprietary archive format not readable by other
> > software, even other backup software, but even if it doesn't, ...
> >
> > - Restoring an individual file can be time-consuming and
> > awkward.
> >
> > - It may be that if a single media in a set is unreadable, then
> > the whole backup set is lost - surprising as it sounds, not to say
> > horrifying as it was to me, I encountered this with an expensive,
> > apparently 'professional' system.
AFAIAA, these points have applied to all the backup programs bundled
with all MS OSs since DOS. In particular, the last point makes them
unsuitable for backing up data, though the OS itself could be backed
up this way reasonably well.
The last point means that the retrieval of ALL data depends critically
on the media from a set which contain the catalogue, which, IMS, are
the last in the set - a SINGLE floppy, tape, CD-R, or whatever
becoming unreadable, and the ENTIRE backup set is lost.
And we all know how unreliable such media can be ...
Suppose such media have an X% chance of failure over the useful life
of a backup set, where X is some fairly small, but not so small as to
be insignificant, number. This means that the probability of failure
during a restore operation of any one given media in the set will be
a fractional number x=X/100, and the probability that it will be read
successfully will therefore be another fractional number y=1-x. For
example, if the original X is 10% - even with floppies too high a
figure to be realistic, but being a simple starting number it makes
the ensuing numbers, and therefore the reasoning, easier to follow -
then x = 0.1, and y = 0.9, or 90%.
Suppose now, as is likely the case, the catalogue is on one media and
a desired file for restoratation is on at least one other (*), then
the probability of the operation's success is y.y, or y^2 - y being
fractional, this is a smaller number than y. With the example numbers
y^2 = 0.81, or 81%, which is significantly smaller than the 90% for
the successful use of any one media in the set.
*A long file may be spread over several such media, each one reducing
the probability of success still further.
So, for backing up data, rather than using such a system, it would be
better just to copy the individual files to the media directly,
because then the chances of successful restoration from any given one
would still be 0.9 = 90%.
Thus, for an archival backup system which can spread over several
media, you need:
1) A data layout that allows the individual remaining media in the
set to be searched for a given file even if the global catalogue for
the set is corrupted. AFAIAA, none of the bundled MS programs, nor,
as I found out to my cost, many of the so-called 'professional'
systems, could do this.
2) An 'open' layout or format that can be read by archival programs
from different OSs - not just different versions of the same OS, but
actually as different as, say, Linux and Windows. However, most
backup programs used a proprietary 'closed' system, although some did
share the same 'closed' format, simply because they were different
badgings of the same underlying product.
Skywise
news:u69sv691ufltdjkvn...@4ax.com:
> So, for backing up data, rather than using such a system, it would be
> better just to copy the individual files to the media directly,
> because then the chances of successful restoration from any given one
> would still be 0.9 = 90%.
That's my thinking for my backup method. No backup software or
method or encoding involved. I remember trouble in the distant
past with corrupted zip files used as backups. Seemed if there
was an error anywhere, I couldn't recover any file.
So, all I do is click & drag the contents to a removable hard
drive.
For the OS drive I do a cloning operation so it's 100% bootable
and usable simply by installing the backup drive. No restore
operation to go wrong.
The only drawback to my method is frequency of backup since it's
a manual operation.
Puddin' Man
partitions. DiP1 i-1,2 was used only to gen standalone backup images (with
PartitionMagic Pro 7.0 or similar) and/or in emergencies. D1P2 was my boot/run
every-day system, and D2P2 was an image of D1P2. D2P2 could be made bootable
(in place) with a registry hack. The primary disadvantage was having to
maintain/update 4 systems.
My old P4 W2k system suffered a massive hardware failure and my new hardware
wouldn't support W2k (else I'd still be running it), so I've now got Win7-64
and XP-32 in dual boot with an identical second HD and using various linux-
live CD's (Part. Wizard, Easeus Part. Master), etc to make image copies, and
with UBCD4Win, BartPE, PartedMagic and GParted for emergencies. Really
surprised no one mentioned any of these: they are game-changers for me. Also
have Paragon Sys Backup installed, but haven't been using it.
To state the obvious, "All backup schemes/strategies have numerous strengths
and weaknesses". The foolproof backup plan is the one virtually guaranteed to
waste resources in an only-marginally-predictable environment.
Salud,
P
On Fri, 10 Jun 2011 23:48:12 -0400, Kil...@SomeISP.gov wrote:
"Law Without Equity Is No Law At All. It Is A Form Of Jungle Rule."