View Single Post
  #14  
Old August 12th 15, 12:41 PM posted to microsoft.public.windowsxp.general,comp.sys.ibm.pc.hardware.storage
Mark F[_2_]
external usenet poster
 
Posts: 164
Default Making two partition copies in turn

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?"