Using EaseUS Todo to create an image

W. eWatson wrote:
I thought I'd install EaseUS Todo today to see if I could create an
image on a M: HD. I found out that it wouldn't put the image on my
C-Drive. Anyone know what's going on?

When you run backup software, the software tends to
enforce "best practice". It encourages you to store
a backup image file, on a separate drive from
the thing you're attempting to protect.

So if you had an internal drive with partitions
on it, and you wanted to backup up all the
partitions, the best place for the image file
is on an external disc.

*******

Nothing prevents the backup image from
going on the *same* partition as the backup.

This is because modern backup software uses
VSS, it requests VSS to "quiesce" the partition,
then takes a volume snapshot. The partition is
now "frozen". When the backup runs, it runs
with respect to the "frozen" copy. Only the
files listed in the "frozen" copy are backed up.

If a user then creates a brand new file,
as the backup is running, the backup "cannot
see it". The backup only knows about the
files in the shadow copy.

So if you stored 12345678.mrimg on C:\downloads
as the backup was running, there is no danger
of an infinite loop. At the instant the output
file 12345678.mrimg is created, the partition
is already "frozen" and the backup software
cannot "see" its own file, to back up that
file by accident.

If the software does not use VSS (unlikely),
then an infinite loop could form. A good
software author would consider and prevent
that from happening.

So when you see various warnings in modern
software, it could be warning you about a
lack of storage space, or it could warn you
from a "best practices" point of view. And
the "best practice" is to store the output
from the backup process, on the external drive.
Or at least, on a physically different hard
drive, so that if the source hard drive is
completely destroyed, the backup image is
safe on that other hard drive.

Paul

Paul wrote:
W. eWatson wrote:
I thought I'd install EaseUS Todo today to see if I could create an
image on a M: HD. I found out that it wouldn't put the image on my
C-Drive. Anyone know what's going on?

When you run backup software, the software tends to
enforce "best practice". It encourages you to store
a backup image file, on a separate drive from
the thing you're attempting to protect.

So if you had an internal drive with partitions
on it, and you wanted to backup up all the
partitions, the best place for the image file
is on an external disc.

*******

Nothing prevents the backup image from
going on the *same* partition as the backup.

This is because modern backup software uses
VSS, it requests VSS to "quiesce" the partition,
then takes a volume snapshot. The partition is
now "frozen". When the backup runs, it runs
with respect to the "frozen" copy. Only the
files listed in the "frozen" copy are backed up.

If a user then creates a brand new file,
as the backup is running, the backup "cannot
see it". The backup only knows about the
files in the shadow copy.

So if you stored 12345678.mrimg on C:\downloads
as the backup was running, there is no danger
of an infinite loop. At the instant the output
file 12345678.mrimg is created, the partition
is already "frozen" and the backup software
cannot "see" its own file, to back up that
file by accident.

If the software does not use VSS (unlikely),
then an infinite loop could form. A good
software author would consider and prevent
that from happening.

So when you see various warnings in modern
software, it could be warning you about a
lack of storage space, or it could warn you
from a "best practices" point of view. And
the "best practice" is to store the output
from the backup process, on the external drive.
Or at least, on a physically different hard
drive, so that if the source hard drive is
completely destroyed, the backup image is
safe on that other hard drive.

Paul

I can't get my head around this backup image on same partition.
Follow me to time of restore and see where I'm going wrong.

C partition is imaged on C partition.
So we're restoring C partition now. EaseUS locates the image file, reads
it sequentially, and writes it to the output partition. But the image is
on that partition, so it's going to overwrite itself.

Ed

Ed Cryer wrote:
Paul wrote:
W. eWatson wrote:
I thought I'd install EaseUS Todo today to see if I could create an
image on a M: HD. I found out that it wouldn't put the image on my
C-Drive. Anyone know what's going on?

When you run backup software, the software tends to
enforce "best practice". It encourages you to store
a backup image file, on a separate drive from
the thing you're attempting to protect.

So if you had an internal drive with partitions
on it, and you wanted to backup up all the
partitions, the best place for the image file
is on an external disc.

*******

Nothing prevents the backup image from
going on the *same* partition as the backup.

This is because modern backup software uses
VSS, it requests VSS to "quiesce" the partition,
then takes a volume snapshot. The partition is
now "frozen". When the backup runs, it runs
with respect to the "frozen" copy. Only the
files listed in the "frozen" copy are backed up.

If a user then creates a brand new file,
as the backup is running, the backup "cannot
see it". The backup only knows about the
files in the shadow copy.

So if you stored 12345678.mrimg on C:\downloads
as the backup was running, there is no danger
of an infinite loop. At the instant the output
file 12345678.mrimg is created, the partition
is already "frozen" and the backup software
cannot "see" its own file, to back up that
file by accident.

If the software does not use VSS (unlikely),
then an infinite loop could form. A good
software author would consider and prevent
that from happening.

So when you see various warnings in modern
software, it could be warning you about a
lack of storage space, or it could warn you
from a "best practices" point of view. And
the "best practice" is to store the output
from the backup process, on the external drive.
Or at least, on a physically different hard
drive, so that if the source hard drive is
completely destroyed, the backup image is
safe on that other hard drive.

Paul

I can't get my head around this backup image on same partition.
Follow me to time of restore and see where I'm going wrong.

C partition is imaged on C partition.
So we're restoring C partition now. EaseUS locates the image file, reads
it sequentially, and writes it to the output partition. But the image is
on that partition, so it's going to overwrite itself.

Ed


I'm referring to the practicality of backing up
to the same partition.

I did *not* say that this would be a clever plan
at restore time. That's an entirely different issue.
There is no "VSS", no "frozen" when restoring. And
as you describe, now that image file is being
destroyed.

If you were to backup C: to C:\Downloads\12345678.mrimg,
you would need to move it to M:\12345678.mrimg at some
point in time. Then, when the hard drive containing
C: suffers a hardware failure, you boot with your
bare metal restoration boot CD, and recover M:\12345678.mrimg
on the external drive, to the new empty hard drive, making
your restored C: .

My point was, that because VSS is involved, the actual
backup step need not suffer an infinite loop. It would
only be an infinite loop, if C:\Downloads\12345678.mrimg
was created before the "vss create" call. And was captured
in the frozen thing. VSS is used to handle the "busy file"
issue during backups, but the side effects can also protect
you from an infinite loop.

Paul

Paul wrote:
Ed Cryer wrote:
Paul wrote:
W. eWatson wrote:
I thought I'd install EaseUS Todo today to see if I could create an
image on a M: HD. I found out that it wouldn't put the image on my
C-Drive. Anyone know what's going on?

When you run backup software, the software tends to
enforce "best practice". It encourages you to store
a backup image file, on a separate drive from
the thing you're attempting to protect.

So if you had an internal drive with partitions
on it, and you wanted to backup up all the
partitions, the best place for the image file
is on an external disc.

*******

Nothing prevents the backup image from
going on the *same* partition as the backup.

This is because modern backup software uses
VSS, it requests VSS to "quiesce" the partition,
then takes a volume snapshot. The partition is
now "frozen". When the backup runs, it runs
with respect to the "frozen" copy. Only the
files listed in the "frozen" copy are backed up.

If a user then creates a brand new file,
as the backup is running, the backup "cannot
see it". The backup only knows about the
files in the shadow copy.

So if you stored 12345678.mrimg on C:\downloads
as the backup was running, there is no danger
of an infinite loop. At the instant the output
file 12345678.mrimg is created, the partition
is already "frozen" and the backup software
cannot "see" its own file, to back up that
file by accident.

If the software does not use VSS (unlikely),
then an infinite loop could form. A good
software author would consider and prevent
that from happening.

So when you see various warnings in modern
software, it could be warning you about a
lack of storage space, or it could warn you
from a "best practices" point of view. And
the "best practice" is to store the output
from the backup process, on the external drive.
Or at least, on a physically different hard
drive, so that if the source hard drive is
completely destroyed, the backup image is
safe on that other hard drive.

Paul

I can't get my head around this backup image on same partition.
Follow me to time of restore and see where I'm going wrong.

C partition is imaged on C partition.
So we're restoring C partition now. EaseUS locates the image file,
reads it sequentially, and writes it to the output partition. But the
image is on that partition, so it's going to overwrite itself.

Ed


I'm referring to the practicality of backing up
to the same partition.

I did *not* say that this would be a clever plan
at restore time. That's an entirely different issue.
There is no "VSS", no "frozen" when restoring. And
as you describe, now that image file is being
destroyed.

If you were to backup C: to C:\Downloads\12345678.mrimg,
you would need to move it to M:\12345678.mrimg at some
point in time. Then, when the hard drive containing
C: suffers a hardware failure, you boot with your
bare metal restoration boot CD, and recover M:\12345678.mrimg
on the external drive, to the new empty hard drive, making
your restored C: .

My point was, that because VSS is involved, the actual
backup step need not suffer an infinite loop. It would
only be an infinite loop, if C:\Downloads\12345678.mrimg
was created before the "vss create" call. And was captured
in the frozen thing. VSS is used to handle the "busy file"
issue during backups, but the side effects can also protect
you from an infinite loop.

Paul

After writing my post I had this thought.

Situation; C: gets imaged onto C:
Maybe several times. So that C: is carrying, say, grandfather, father,
son of its own state.

For some reason you want to restore from, say, grandfather. Well, you
could copy that image to an external HD, and do a simple restore from there.
Or (and this was the thought) you could restore from the image onto an
external HD, and then open the case and put that inside, replacing the
current one.

Hhhmm! Not quite as effectual as saving images straight to an external
HD; but it could work.

Ed

On 4/9/2015 5:10 PM, Gene E. Bloch wrote:
On Thu, 09 Apr 2015 14:34:39 -0700, W. eWatson wrote:

See dadi HO for more insight. More below.

On 4/9/2015 10:35 AM, Stormin' Norman wrote:
On Thu, 09 Apr 2015 10:09:58 -0700, "W. eWatson" wrote:

I thought I'd install EaseUS Todo today to see if I could create an
image on a M: HD. I found out that it wouldn't put the image on my
C-Drive. Anyone know what's going on?

I use Easeus Todo extensively.

Make sure you are not attempting to "clone" one disk to another. You want to
create an "image" of a disk or partition and store it on a different disk or
partition.

For example, make an image of the C: partition and store that image on the M:
partition. Under this scenario, the partitions can be on the same or different
disks.
From what I see in the EaseUS Todo System Backup dialog, it shows a

Windows 7 SV Pack 1
C:\*:\ C:\*:\
686.696GB.


Destination is C:\My Backups

Presumably the C-drive is a single partition. I'm not quite partition
savvy.)

Is that the the image? It seems that it would clobber C:\*:\.

How do I make a partition on M:?

The notation "C:\*:\" makes no sense at all. What are you miscopying?
It's under Location.

Titles on System Backup.
System Name Location Size
Windows 7 SV Pack 1 C:\*:\ 686.79G

Destination is c:\My Backup\, as above.

And no, the destination should not be C: anything. For what you wrote, I
can't guess what you are doing.

Go to Disk Management to make a partition on M if it doesn't have one
already.

You are not going to be able to make an image of all partitions on a disk and at
the same time store it to one of the partitions you are attempting to image.
Likewise, if you are attempting to make an image of C: you cannot write that
image to the C: drive while you are creating the image.

On Thu, 09 Apr 2015 23:30:56 -0400, Paul wrote:

Nothing prevents the backup image from
going on the *same* partition as the backup.

This is because modern backup software uses
VSS, it requests VSS to "quiesce" the partition,
then takes a volume snapshot. The partition is
now "frozen". When the backup runs, it runs
with respect to the "frozen" copy. Only the
files listed in the "frozen" copy are backed up.

If a user then creates a brand new file,
as the backup is running, the backup "cannot
see it". The backup only knows about the
files in the shadow copy.

That's what I would have thought, except once I tried to do that and it
was not permitted.

It was a while ago, so maybe:

1. It was a non-VSS programs, and

2. I no longer recall the details, but I might have done something
weird, like using a mount point "folder" on C: to send the output to an
external drive. I.e, perhaps I was being creative and thereby shot
myself in the USB port or something.

--
Gene E. Bloch (Stumbling Bloch)