Making two partition copies in turn

In microsoft.public.windowsxp.general, on Sun, 9 Aug 2015 16:15:23
+0100, Ian Jackson wrote:

In message , "Ken Blake,
MVP" writes
On Sun, 09 Aug 2015 08:33:45 -0400, micky
wrote:

I'm maintaining two (maybe even 3) copies of my C: drive.

I've been copying everything from C to F and to H, but I'm thinking,
maybe it would be better to copy C to F and then F to H.

It would lessen the wear on the C drive, especially when I copy every
single file (except the ones I don't copy.)

Any reason not to do it this indirect way?

Any reason to do it besides saving wear on the C: drive?

What say ye?


Why are you doing this? Is it for backup purposes?

If so, it's better than no backup at all, but just barely. It's the
worst possible way to backup.

I don't recommend backup to a second non-removable hard drive because
it leaves you susceptible to simultaneous loss of the original and
backup to many of the most common dangers: severe power glitches,
nearby lightning strikes, virus attacks, even theft of the computer.

Even worse is what you are doing--backing up to partitions on the same
hard drive. If the drive dies, all your backups die with it.

In my view, secure backup needs to be on removable media, and not kept
in the computer. For really secure backup (needed, for example, if the
life of your business depends on your data) you should have multiple
generations of backup, and at least one of those generations should be
stored off-site.

I wish I had been reading to correct the misimpression earlier. I tried
to make the OP short and sweet and that causes its own problems.

The OP doesn't say whether drives F and H are internal or external. As

They're external.

you say, external would be preferred, but I wouldn't have thought that
the data on the C-drive would be get corrupted if it wasn't being
written to (which presumably it isn't - especially if the
cloning/imaging program is running from a CD or DVD). Of course, damage

Yes, from a CD.

from things like lightning strikes is a different matter, and there's a
limit on what you can do.

As for copying C to F and C to H, and C to F, then F to H, I can't see
it making much difference. The latter has the advantage of allowing you
to use the computer when you're doing F to H (although this will
probably slow it down).


F and H are on two separate HDDs but they don't have consecutive letters
because one can't buy a small HDD anymore (and it would be more money
per byte if you could). So with all the extra empty space, I put more
partitions on each drive. A backup of my laptop, etc. They are
sometimes** both plugged in because I use internal-style drives in a
BlacX double dock. So if and when my C: drive fails, I can just mount
one of the two copies inside the computer and it should be run right off
the bat.

When I set this up, I tried or at least intended to put all the data in
another partition, on another drive, but something interfered and it
didn't get done. I also tried to put all the data in one directory,
and that got done mostly. So most of my backups are just c:\. c:\data
c:\downloads and c:\...\Agent-data.

For some reason I don't remember, Agent data got stuck in a separate
directory. Well I guess I just didn't take the extra trouble to put it
in C:\data, but maybe I will eventually.


A complete backup is coming up soon because it has finally come to my
attention that open and/or locked files were likely not backed up during
all the previous backups. I've been reading articles, not all of them
of course, both in newsgroups and on the web, on PC maintenance for 20
years, and afaicr, no one really emphasized this until lately. At least
not enough for my slow mind to absorb. Maybe it's a feature of some
good backup programs, but if they mention it, they don't mention it
strongly enough that I realized the feature was missing from what I was
using. If they said they were bootable, they didn't say why that
mattered, and it didn't dawn on me. I would ask about all this the
author of the software I have been using lately, but he's been sick.


Thanks.


**They would be connected less if I could get Safely Remove Hardware to
work more often. Well, it worked just now, for the first time! and
disconnected all the partitions on both drives, even though I only
highlighted one partition. Maybe that's because they're all connected
via one USB port.

wrote:
On Sun, 9 Aug 2015 15:19:09 -0600, "Bill in Co"
wrote:

J. P. Gilliver (John) wrote:
In message ,
writes:
[]
I have said this before but you should be separating your system files
from your data files.
Your system files should be all that you have on your C: and you
should be imaging that drive because that is the best way to get your
machine going after a crash. If it is just your software, the drive is
relatively small. I would even suggest this should be RAID 1
(mirrored). Then it will usually fail "soft".
Then you put your big stuff, the data, on another drive or two and you
can just copy that. I like to keep lots of copies of this stuff and a
lot of it is in the cloud. That is the stuff you can't rebuild and
buying a new machine will not get you back.

I'm with you all the way, except on the cloud - certainly keeping
OS-and-installed-software on one drive, or at least partition, which you
image, and your data on another, which you copy (both to a different
physical drive, and ideally not in the same machine).

There are, however, many who disagree with us about the separation of
OS-and-software from data.

And after all these years, I still haven't come up with the best or most
definitive answer to that question, either! So I think it really
depends
on some other factors based on your own practices. Like for example:

IF you are making relatively frequent changes to both the software or OS
and
your data, it may be simpler to keep it all together on one backup image
(which you frequently backup), as it's all together then in one complete
image, and you won't have to be backing up two separate partitions
together all the time.

If, OTOH, you rarely install anything new (or make other changes to your
OS), then maybe it's worth keeping two separate backup images (one for
the
OS and programs, which you will rarely need to backup, and the other for
the data, which you will often backup. (So this will generally be a
lot
faster - but only for this particular case).

And, of course, in either case it should be on another drive, not the
same
drive.


Drives are cheap. There are 5 of them in this system, 2 mirrored sets.
I also have a cabinet full of "old soldiers" most that contain old data.
By definition we are clinging to XP so our software is pretty static
;-)

Well, not so much over here! Every time I try out some new software or
other experiments, I first make a backup image of the C: partition. And
sometimes that software stays installed, sometimes not. This happens quite
often, since I have the time and interest.

So for me, I really do need to make routine backups of *both* my system and
data, not just the data. But if I didn't change anything on my system like
you mentioned, I think separating the two for backup purposes would make
more sense, as I'd only have to routinely backup the data stuff, and would
rarely need to update the system backup. And that would be faster, of
course.

I image whenever I make a major change (before and after) so I have a
good place to go back to. (again the advantage of a small C

Same here! But even with my data, it doesn't take too long to either image
it or restore it (about 40 GB, en total, less music and video files).
(Note: For data, I'm not talking about routinely backing up all my music and
video files routinely, which rarely change, and which are on two other
partitions).

I have been doing this computer stuff since the Johnson
Administration. I understand data loss.

I've been doing this computer stuff since FDR's administration. :-) I
understand it too - to an extent. :-)

On Sun, 09 Aug 2015 21:34:03 -0400, micky
wrote:

In microsoft.public.windowsxp.general, on Sun, 9 Aug 2015 16:15:23
+0100, Ian Jackson wrote:

In message , "Ken Blake,
MVP" writes
On Sun, 09 Aug 2015 08:33:45 -0400, micky
wrote:

I'm maintaining two (maybe even 3) copies of my C: drive.

I've been copying everything from C to F and to H, but I'm thinking,
maybe it would be better to copy C to F and then F to H.

It would lessen the wear on the C drive, especially when I copy every
single file (except the ones I don't copy.)

Any reason not to do it this indirect way?

Any reason to do it besides saving wear on the C: drive?

What say ye?


Why are you doing this? Is it for backup purposes?

If so, it's better than no backup at all, but just barely. It's the
worst possible way to backup.

I don't recommend backup to a second non-removable hard drive because
it leaves you susceptible to simultaneous loss of the original and
backup to many of the most common dangers: severe power glitches,
nearby lightning strikes, virus attacks, even theft of the computer.

Even worse is what you are doing--backing up to partitions on the same
hard drive. If the drive dies, all your backups die with it.

In my view, secure backup needs to be on removable media, and not kept
in the computer. For really secure backup (needed, for example, if the
life of your business depends on your data) you should have multiple
generations of backup, and at least one of those generations should be
stored off-site.

I wish I had been reading to correct the misimpression earlier. I tried
to make the OP short and sweet and that causes its own problems.


OK, glad I was wrong and that they are external.

In message , micky
writes


So with all the extra empty space, I put more
partitions on each drive. A backup of my laptop, etc.

Understood. I've done similar (for experimentation). There's no point in
using the whole of a 1TB external disk for a 100GB backup.

However, if the external disk fails, you've lost several backups, so
maybe this isn't too good an idea.

Like 'gfretwel', I have a collection of 'old soldiers' to use for
backups and generally play around with, and it's probably best to do one
backup per disk.

If the 'old soldiers' are smaller than you present C-drive (which
they're likely to be), you can always temporarily resize (shrink) the
C-drive partition before doing the backup. However, I suppose that there
is the a chance that the resizing process might fail, and screw up your
C-drive data. Maybe here is a case for first doing a full-size backup,
and then a 'spare' reduced-size one (maybe to a multi-partition disk).
It really all depends how much spare time you have!
--
Ian

On Sun, 09 Aug 2015 08:33:45 -0400, micky
wrote:

I'm maintaining two (maybe even 3) copies of my C: drive.

I've been copying everything from C to F and to H, but I'm thinking,
maybe it would be better to copy C to F and then F to H.

It would lessen the wear on the C drive, especially when I copy every
single file (except the ones I don't copy.)

Any reason not to do it this indirect way?
I typically do something like
C to F, then F to G then compare C and G

This saves some time versus comparing C and F.
It assumes that the process is reliable enough to that
the C versus G compare only has explainable differences.

Another advantage besides the time saving is that you have 2
backups that may match and didn't have to keep your system down
while both copies were made. (I say "may" match since I have
found that some backup programs give slightly different results
for what should would seem to be the same backup due to
what seems to be something to do with NTFS journal ling, even though
the systems was initially shutdown normally and completely. I
have only seen the problem with NTFS partitions and the system
partition. The issue happened with Windows XP. I don't know if
it happens with Windows Vista or later.)


Any reason to do it besides saving wear on the C: drive?

What say ye?

In microsoft.public.windowsxp.general, on Mon, 10 Aug 2015 10:18:31
-0400, Mark F wrote:

On Sun, 09 Aug 2015 08:33:45 -0400, micky
wrote:

I'm maintaining two (maybe even 3) copies of my C: drive.

I've been copying everything from C to F and to H, but I'm thinking,
maybe it would be better to copy C to F and then F to H.

It would lessen the wear on the C drive, especially when I copy every
single file (except the ones I don't copy.)

Any reason not to do it this indirect way?
I typically do something like
C to F, then F to G then compare C and G

So that finds errors in both copy steps at the same time. It doesnt'
tell you which step made the error but I suppose that usually there are
no errors.

What do you use to compare?

I have /v for verify when I'm running. I thnk you mean more than that.

This saves some time versus comparing C and F.
It assumes that the process is reliable enough to that
the C versus G compare only has explainable differences.

Another advantage besides the time saving is that you have 2
backups that may match and didn't have to keep your system down
while both copies were made.

Yeah, I hadn't thought about that. I'm still living in the mental world
where I made backups while running Windows.

Using your drive letters:
Also, I could make the first version of G: from scratch and make it an
exact copy of F with no exclusions etc. Then perhaps subsequent
updates could come straigtht from C:

(I say "may" match since I have
found that some backup programs give slightly different results
for what should would seem to be the same backup due to
what seems to be something to do with NTFS journal ling, even though
the systems was initially shutdown normally and completely. I
have only seen the problem with NTFS partitions and the system

I knew I should have stuck with FAT32. If it was good enough for my
grandmother, it should have been good enough for me**.

partition. The issue happened with Windows XP. I don't know if
it happens with Windows Vista or later.)


Any reason to do it besides saving wear on the C: drive?

What say ye?

**My grandmother used to say "By cracky, FAT thirty two is the only way
to go. Now where is my cider?"

On Tue, 11 Aug 2015 00:05:20 -0400, micky
wrote:

In microsoft.public.windowsxp.general, on Mon, 10 Aug 2015 10:18:31
-0400, Mark F wrote:

On Sun, 09 Aug 2015 08:33:45 -0400, micky
wrote:

I'm maintaining two (maybe even 3) copies of my C: drive.

I've been copying everything from C to F and to H, but I'm thinking,
maybe it would be better to copy C to F and then F to H.

It would lessen the wear on the C drive, especially when I copy every
single file (except the ones I don't copy.)

Any reason not to do it this indirect way?
I typically do something like
C to F, then F to G then compare C and G

So that finds errors in both copy steps at the same time. It doesnt'
tell you which step made the error but I suppose that usually there are
no errors.

What do you use to compare?
I use Syncovery www.syncovery.com.
Before that I used
FolderMatch from Salty Brine Software www.foldermatch.com

Syncovery runs faster and doesn't skip as many files as FolderMatch.
(A few files are not compared by either in Symantec AntiVirus's areas
and a few other areas because of access rights issues.)

FolderMatch is a bit easier to use for ad hoc operations.

Both programs find all of the files for data partitions and I haven't
seen any differences in cloned images on data partitions. I take
steps to avoid having paging files in data partitions when cloning.

I usually don't boot from another device and compare the
clones, so there could be some issues with the page file, swap file,
and a couple of other files that the booted from operating system
changes and so therefore don't match when compared, so on any
given clone operation might not have been copied correctly.

To validate the cloning programs I have used 2 different
cloning programs on the system device and compared both on another
system using forensic write blockers
(http://www.cru-inc.com/products/wiebetech/
that don't allow writes and the only unchecked
files with those with access rights issues. (Note I didn't use
what are now current www.cru-inc write blockers)

When I validated my procedures, which was perhaps 5 years ago,
I did many other tests to make sure that everything matched
in partitions that normally are not mounted, and except for
what I think are issues in the journaling areas of NTFS partitions
there were no differences. Since then I have trusted the
cloning programs to complain if the operations didn't
work correctly on the files that are expected not to match.

The most recent cloning operations that I did were for new
Samsung SSD's and I used the included software to compare
during the clone operation and compared using Syncovery
using the newly cloned disk as the system disk. For
these operations the cloning compare operation didn't find
any issues and the Syncovery compare only had the expected
access issues and differences in files where differences
were expected. (I didn't see any differences in the journaling
areas, but Syncovery wouldn't see them when running on
one of the partitions being compared.)


I have /v for verify when I'm running. I thnk you mean more than that.

This saves some time versus comparing C and F.
It assumes that the process is reliable enough to that
the C versus G compare only has explainable differences.

Another advantage besides the time saving is that you have 2
backups that may match and didn't have to keep your system down
while both copies were made.

Yeah, I hadn't thought about that. I'm still living in the mental world
where I made backups while running Windows.

Using your drive letters:
Also, I could make the first version of G: from scratch and make it an
exact copy of F with no exclusions etc. Then perhaps subsequent
updates could come straigtht from C:

(I say "may" match since I have
found that some backup programs give slightly different results
for what should would seem to be the same backup due to
what seems to be something to do with NTFS journal ling, even though
the systems was initially shutdown normally and completely. I
have only seen the problem with NTFS partitions and the system

I knew I should have stuck with FAT32. If it was good enough for my
grandmother, it should have been good enough for me**.

partition. The issue happened with Windows XP. I don't know if
it happens with Windows Vista or later.)


Any reason to do it besides saving wear on the C: drive?

What say ye?

**My grandmother used to say "By cracky, FAT thirty two is the only way
to go. Now where is my cider?"

On 8/10/2015 1:28 AM, Ian Jackson wrote:


Like 'gfretwel', I have a collection of 'old soldiers' to use for
backups and generally play around with, and it's probably best to do one
backup per disk.

If the 'old soldiers' are smaller than you present C-drive (which

You could use Image for DOS (on a CD or thumb drive) to make a system
image. It will probably be half the size of the data. You should set it
to ignore the page and hibernation files. Next time you can just backup
the changes. That's at

http://www.terabyteunlimited.com/image-for-dos.htm

I'd also turn on byte-for-byte verify. Then you know you got everything
safely.

--
Ed Light

Better World News TV Channel:
http://realnews.com

Iraq Veterans Against the War and Related:
http://ivaw.org
http://couragetoresist.org
http://antiwar.com

Send spam to the FTC at

Thanks, robots.

On 8/10/2015 9:05 PM, micky wrote:


I knew I should have stuck with FAT32.

When Win 98 was using that, any crash would make a bunch of errors that
chkdsk would find. Now, it doesn't happen much at all. Also, you're
limited to 2 Gig maximum file size.

--
Ed Light

Better World News TV Channel:
http://realnews.com

Iraq Veterans Against the War and Related:
http://ivaw.org
http://couragetoresist.org
http://antiwar.com

Send spam to the FTC at

Thanks, robots.

On Thu, 20 Aug 2015 18:16:24 -0700, Ed Light wrote:

On 8/10/2015 9:05 PM, micky wrote:


I knew I should have stuck with FAT32.

When Win 98 was using that, any crash would make a bunch of errors that
chkdsk would find. Now, it doesn't happen much at all. Also, you're
limited to 2 Gig maximum file size.

That was FAT16 that had a 2GB file size limit. FAT32 has a 4GB file size
limit. In both cases, minus 1 byte, but who's counting.

I agree with your observation on the frailty of FAT32. NTFS is much better
in that regard.