Restoring an image after repartitioning the image restore drive?

[Bill in Co.]

I'm a little confused about this:

I save several (different-dated) system images on my backup drive, with a
pretty large partition reserved just for storing those system drive (C: )
images (the rest of the space on that drive is still unallocated).

Now suppose I increase the size of the partition on the backup drive (which
stores those images) to make more room for more of them, and subsequently
save a few more backup images. Ok, no problem so far.

But now if decide to restore a much earlier image (where the partition size
on the backup drive was previously allocated as being much smaller), will I
then lose the ability to access the newer and later image,s where I had
later expanded the partition?

I'm guessing it won't be a problem, and after the system reboots to restore
the system drive backup, BIOS will report the new partition size to windows,
and there won't be an issue, but I'm not sure of this.

 

[Pegasus [MVP]]

I'm a little confused about this:

I save several (different-dated) system images on my backup drive, with a
pretty large partition reserved just for storing those system drive (C: )
images (the rest of the space on that drive is still unallocated).

Now suppose I increase the size of the partition on the backup drive
(which stores those images) to make more room for more of them, and
subsequently save a few more backup images. Ok, no problem so far.

But now if decide to restore a much earlier image (where the partition
size on the backup drive was previously allocated as being much smaller),
will I then lose the ability to access the newer and later image,s where I
had later expanded the partition?

I'm guessing it won't be a problem, and after the system reboots to
restore the system drive backup, BIOS will report the new partition size
to windows, and there won't be an issue, but I'm not sure of this.

The answer hinges on the program used to create the image (which you never
mention). Good programs, e.g. Acronis True Image, will restore any image to
any partition, as long as it is sufficiently large to hold the data. Bad
ones will require a target partition that is the same size as the original
partition.

Your question implies that you never tested your imaging facility. This
greatly reduces its value. Any backup process is only worth its name if it
gets tested at setup time and then again once or twice each year. I have
seen numerous instances of people backing up their data religiously for
months or years, only to find that the backups were unusable because of some
setup error.

 

[Bill in Co.]

The answer hinges on the program used to create the image (which you never
mention). Good programs, e.g. Acronis True Image, will restore any image
to
any partition, as long as it is sufficiently large to hold the data. Bad
ones will require a target partition that is the same size as the original
partition.

I'm not sure if we're on the same page on this, but I think so. But just
to be sure:
The problem I'm mentioning may come about due to the recorded size of the
partition as it was specified within the system image backup itself, and
what happens if you restore an image which has embedded within it a
different allocation size, since that information is stored within each of
the image backups. Maybe we're saying the same thing though, and it's not
an issue (with Acronis).

Your question implies that you never tested your imaging facility. This
greatly reduces its value. Any backup process is only worth its name if it
gets tested at setup time and then again once or twice each year. I have
seen numerous instances of people backing up their data religiously for
months or years, only to find that the backups were unusable because of
some
setup error.

I'm using Acronis True Image.

No, I've tested the restore capability on numerous times, and it's been
working great, but I have not done the specific test mentioned above.

That is, I haven't yet enlarged my system backup's partition size, stored
some more images, and then tried restoring an earlier system backup image
(where the recorded partition size was much smaller).

Since the backup drive's partition size info is stored within each image, I
can see how it might be a problem, and perhaps render unobtainable any
images stored beyond the original partition size (as recorded in that
image). Does that explain it?

 

[Bill in Co.]

Pegasus, let me ask again, since I'm still not clear about this, and I'd
rather find out here than after the fact:

The answer hinges on the program used to create the image (which you never
mention). Good programs, e.g. Acronis True Image, will restore any image
to any partition, as long as it is sufficiently large to hold the data.
Bad
ones will require a target partition that is the same size as the original
partition.

The problem I'm thinking of may come about due to the recorded size of the
system partition *as specified within the system image backup itself*, and
what happens if you restore an image which has embedded within it a
different partition allocation size (since that information is stored within
each of
the image backups). Keep in mind I'm restoring my system drive C:, so it's
critical what exactly related to this was stored in that restored image (at
the time it was taken). More on that below.

Your question implies that you never tested your imaging facility. This
greatly reduces its value. Any backup process is only worth its name if it
gets tested at setup time and then again once or twice each year. I have
seen numerous instances of people backing up their data religiously for
months or years, only to find that the backups were unusable because of
some setup error.

I'm using Acronis True Image.
No, I've tested the system restore capability on numerous times, and it's
been
working great, BUT I have not done the specific test mentioned above.
That is, I haven't yet enlarged my system backup's partition size, stored
some more images, and then tried restoring an earlier system backup image
where the recorded backup partition size was smaller, so that any
information beyond that partition size may be unavailable now.

In other words, since the backup drive's partition size is stored within
each image, I can see how it might be a problem, and perhaps render
unobtainable any
images stored beyond the original partition size (as recorded in that
image).

That is, after rebooting to restore the system drive image, the backup drive
will now show the original partition size (since that was stored in its
image), and not the newly enlarged one, so that any images stored after that
are effectively unavailable, since the partition size is set back to the
original (smaller) size as far as windows is concerned. Does that explain
it?

 

[Pegasus [MVP]]

Pegasus, let me ask again, since I'm still not clear about this, and I'd
rather find out here than after the fact:


The problem I'm thinking of may come about due to the recorded size of the
system partition *as specified within the system image backup itself*, and
what happens if you restore an image which has embedded within it a
different partition allocation size (since that information is stored
within each of
the image backups). Keep in mind I'm restoring my system drive C:, so
it's critical what exactly related to this was stored in that restored
image (at the time it was taken). More on that below.


I'm using Acronis True Image.
No, I've tested the system restore capability on numerous times, and it's
been
working great, BUT I have not done the specific test mentioned above.
That is, I haven't yet enlarged my system backup's partition size, stored
some more images, and then tried restoring an earlier system backup image
where the recorded backup partition size was smaller, so that any
information beyond that partition size may be unavailable now.

In other words, since the backup drive's partition size is stored within
each image, I can see how it might be a problem, and perhaps render
unobtainable any
images stored beyond the original partition size (as recorded in that
image).

That is, after rebooting to restore the system drive image, the backup
drive will now show the original partition size (since that was stored in
its image), and not the newly enlarged one, so that any images stored
after that are effectively unavailable, since the partition size is set
back to the original (smaller) size as far as windows is concerned. Does
that explain it?

Early versions of PQ Magic (from PowerQuest) would restore images to a
partition that would be the same size as the original partition. Restoring
to a smaller partition was impossible, even if the amount of data would have
allowed it. Later versions of the product overcame this limitation, as did
all versions of Acronis Drive Image. However, if you need to be sure without
a trace of doubt then you must test this claim yourself rather than relying
on the advice given by a stranger.

 

[Bill in Co.]

OR anyone else if they can understand what I'm asking about. More
below...

Early versions of PQ Magic (from PowerQuest) would restore images to a
partition that would be the same size as the original partition. Restoring
to a smaller partition was impossible, even if the amount of data would
have
allowed it.

But that's not what I was asking about, Pegasus. My C: source drive is -
and has remained - unchanged in its partition allocations. I'm not talking
about that drive.

The ONLY thing I would have changed would be the size of the partition
allocated on the BACKUP drive used to store the images to make more room.
So it's not a question of restoring to a drive with insufficient room.

But again, I thought this operation might be problematic, as every time you
restore an image, it also (presumably) restores the information on the
partition sizes of all drives, and as far as windows is concerned, the
backup partition size may then look as small as it originally was after
restoring an earlier image, thus rendering any subsequent images stored on
the backup drive, inaccessible. Does that clarify what I'm asking? I
just am trying to understand this better.

OR - maybe the partition size of the backup drive is completely immaterial
after restoring any image from any other drive, as BIOS, and then windows,
automatically takes care of the changes after the system drive reboots to
complete the restore operation, so that the larger partition recently
created on the backup drive will be recognized (and the later images
accessible).

 

[Anna]

I'm a little confused about this:

I save several (different-dated) system images on my backup drive, with a
pretty large partition reserved just for storing those system drive (C: )
images (the rest of the space on that drive is still unallocated).

Now suppose I increase the size of the partition on the backup drive
(which stores those images) to make more room for more of them, and
subsequently save a few more backup images. Ok, no problem so far.

But now if decide to restore a much earlier image (where the partition
size on the backup drive was previously allocated as being much smaller),
will I then lose the ability to access the newer and later image,s where I
had later expanded the partition?

I'm guessing it won't be a problem, and after the system reboots to
restore the system drive backup, BIOS will report the new partition size
to windows, and there won't be an issue, but I'm not sure of this.

(Bill adds...)

The problem I'm mentioning may come about due to the recorded size of the
partition as it was specified within the system image backup itself, and
what happens if you restore an image which has embedded within it a
different allocation size, since that information is stored within each of
the image backups. Maybe we're saying the same thing though, and it's
not an issue (with Acronis).

I'm using Acronis True Image.

No, I've tested the restore capability on numerous times, and it's been
working great, but I have not done the specific test mentioned above.

That is, I haven't yet enlarged my system backup's partition size, stored
some more images, and then tried restoring an earlier system backup image
(where the recorded partition size was much smaller).

Since the backup drive's partition size info is stored within each image,
I can see how it might be a problem, and perhaps render unobtainable any
images stored beyond the original partition size (as recorded in that
image). Does that explain it?

My C: source drive is - and has remained - unchanged in its partition
allocations. I'm not talking about that drive.

The ONLY thing I would have changed would be the size of the partition
allocated on the BACKUP drive used to store the images to make more room.
So it's not a question of restoring to a drive with insufficient room.

But again, I thought this operation might be problematic, as every time
you restore an image, it also (presumably) restores the information on the
partition sizes of all drives, and as far as windows is concerned, the
backup partition size may then look as small as it originally was after
restoring an earlier image, thus rendering any subsequent images stored on
the backup drive, inaccessible. Does that clarify what I'm asking? I
just am trying to understand this better.

OR - maybe the partition size of the backup drive is completely immaterial
after restoring any image from any other drive, as BIOS, and then windows,
automatically takes care of the changes after the system drive reboots to
complete the restore operation, so that the larger partition recently
created on the backup drive will be recognized (and the later images
accessible).

Bill:
Based on previous posts between us re this general subject of
disk-cloning/disk-imaging issues I'm pretty sure you're aware that I use the
disk-imaging capability of the Acronis True Image program on a very
infrequent basis (more for experimentation and resolving user problems for
the most part). Again, as I think you know, I much prefer the Casper
disk-cloning program as a vehicle for the great majority of PC users in
establishing & maintaining a comprehensive backup program of their systems.
I only mention the preceding because while I believe my following comments
are factual as they relate to the ATI program in general, take into account
the fact that I haven't had extensive experience with recent versions of the
ATI program.

Obviously you're maintaining "generational" copies (backups) of your
day-to-day working HDD. (As an aside this is the one particular area (in our
view) where generally speaking a disk-imaging program will serve the user's
needs better than a disk-cloning program.)

It's hard to imagine that the size of the partition you established on your
"destination" HDD serving to contain the various disk-images
(files/archives) will have any relevance (impact) bearing on the potential
problem/issue you've raised. Obviously all that's required re the size of
the partition you create on the external HDD is that it be large enough to
contain the disk-image files/archives you've created over a period of time.
And if & when it becomes necessary to increase the size of that partition to
contain add'l disk-image files/archives it's relatively simple to do so as
you know. And the additional size of the partition should have no impact on
the already-contained disk-image files/archives stored on the partition in
terms of any future restoration process involving *any* of those
disk-images.

Thus the size of the destination partition is really of no consequence as
related to the restoration operation (as I believe you suspect). The fact
that you may have increased the size of the partition following any number
of previous disk-image files/archives stored on the previous smaller-sized
partition is of no relevance as it pertains to any future restoration
process.

It simply doesn't matter which one of the "x" number of disk-image
files/archives residing on the external drive's partition you select for
restoration purposes. Obviously all that is necessary is that recipient HDD
to be restored has sufficient disk space to accommodate the restoration
process, the size of the destination drive's partition notwithstanding
(regardless of whether it had been changed in size along the way).

While I'm assuming my above comments are correct, again, I haven't worked in
any extensive way with recent versions of the Acronis program so it's
conceivable I may be "off-base" as they pertain to the issue you raised. If
so, hopefully, someone more familiar with the program (including yourself!)
will correct me.
Anna

 

[Bill in Co.]

(Bill adds...)




Bill:
Based on previous posts between us re this general subject of
disk-cloning/disk-imaging issues I'm pretty sure you're aware that I use
the
disk-imaging capability of the Acronis True Image program on a very
infrequent basis (more for experimentation and resolving user problems for
the most part). Again, as I think you know, I much prefer the Casper
disk-cloning program as a vehicle for the great majority of PC users in
establishing & maintaining a comprehensive backup program of their
systems.
I only mention the preceding because while I believe my following comments
are factual as they relate to the ATI program in general, take into
account
the fact that I haven't had extensive experience with recent versions of
the
ATI program.

Obviously you're maintaining "generational" copies (backups) of your
day-to-day working HDD. (As an aside this is the one particular area (in
our
view) where generally speaking a disk-imaging program will serve the
user's
needs better than a disk-cloning program.)

It's hard to imagine that the size of the partition you established on
your
"destination" HDD serving to contain the various disk-images
(files/archives) will have any relevance (impact) bearing on the potential
problem/issue you've raised. Obviously all that's required re the size of
the partition you create on the external HDD is that it be large enough to
contain the disk-image files/archives you've created over a period of
time.
And if & when it becomes necessary to increase the size of that partition
to
contain add'l disk-image files/archives it's relatively simple to do so as
you know. And the additional size of the partition should have no impact
on
the already-contained disk-image files/archives stored on the partition in
terms of any future restoration process involving *any* of those
disk-images.

Thus the size of the destination partition is really of no consequence as
related to the restoration operation (as I believe you suspect). The fact
that you may have increased the size of the partition following any number
of previous disk-image files/archives stored on the previous smaller-sized
partition is of no relevance as it pertains to any future restoration
process.

It simply doesn't matter which one of the "x" number of disk-image
files/archives residing on the external drive's partition you select for
restoration purposes. Obviously all that is necessary is that recipient
HDD
to be restored has sufficient disk space to accommodate the restoration
process, the size of the destination drive's partition notwithstanding
(regardless of whether it had been changed in size along the way).

While I'm assuming my above comments are correct, again, I haven't worked
in
any extensive way with recent versions of the Acronis program so it's
conceivable I may be "off-base" as they pertain to the issue you raised.
If
so, hopefully, someone more familiar with the program (including
yourself!)
will correct me.
Anna

Hi Anna, thanks for the reply. But I think I'm having difficulty getting
my point across. The issue I'm getting at is not a matter of insufficient
disk space for storing the images, but that seems to be what I am having a
hard time getting across.

The issue is this:
When one restores an image of their system drive partition (C, also
included within that image I presume is the previously stored information
about the backup drive's partition size *as it was at the time that image
was taken*, which in my mind may present a problem:

Let me give a specific example. Suppose the backup drive originally has a
100 GB partition reserved to store my system drive image backups. And I
keep saving generational images of my system drive to that 100 GB partition.
Naturally after a few backups, it fills up (keep in mind these images are of
the entire C: partition of my source drive which stores all programs, etc.
Typically the image size is around 15 GB per image).

OK, it gets full now, so I now decide to expand the backup partition size to
150 GB to make room for more generational images. So far, so good, and I
can safely store more generational backup images.

Now suppose I decide to restore a very early system drive image, which had
been stored when the backup partition size *was recorded as being 100 GB*.

OK, that image should be restored successfully (after rebooting), I expect -
no problems so far.

BUT - now if I look at the backup drive in windows explorer, will it appear
to be only 100 GB in size (since THAT was the backup partition size
information that was originally "recorded" in its image), OR will the backup
drive correctly appear to be 150 GB (which is what it should be), and allow
thus access to all the later images? Remember, strictly speaking, if I
restore an earlier system drive image, at that time the backup drive
partition size was onlt set at 100 GB in size, so that's what windows may
now think it is, after restoring that image.

IOW, I'm assuming that restoring an image can impact partition size
information, but that may be an incorrect assumptionm

 

[Pegasus [MVP]]

"Bill in Co." <[email protected]> said this in news item

Hi Anna, thanks for the reply. But I think I'm having difficulty
getting my point across. The issue I'm getting at is not a matter of
insufficient disk space for storing the images, but that seems to be what
I am having a hard time getting across.

The issue is this:
When one restores an image of their system drive partition (C, also
included within that image I presume is the previously stored information
about the backup drive's partition size *as it was at the time that image
was taken*, which in my mind may present a problem:

Let me give a specific example. Suppose the backup drive originally has
a 100 GB partition reserved to store my system drive image backups. And
I keep saving generational images of my system drive to that 100 GB
partition. Naturally after a few backups, it fills up (keep in mind these
images are of the entire C: partition of my source drive which stores all
programs, etc. Typically the image size is around 15 GB per image).

OK, it gets full now, so I now decide to expand the backup partition size
to 150 GB to make room for more generational images. So far, so good,
and I can safely store more generational backup images.

Now suppose I decide to restore a very early system drive image, which had
been stored when the backup partition size *was recorded as being 100 GB*.

OK, that image should be restored successfully (after rebooting), I
expect - no problems so far.

BUT - now if I look at the backup drive in windows explorer, will it
appear to be only 100 GB in size (since THAT was the backup partition size
information that was originally "recorded" in its image), OR will the
backup drive correctly appear to be 150 GB (which is what it should be),
and allow thus access to all the later images? Remember, strictly
speaking, if I restore an earlier system drive image, at that time the
backup drive partition size was onlt set at 100 GB in size, so that's what
windows may now think it is, after restoring that image.

IOW, I'm assuming that restoring an image can impact partition size
information, but that may be an incorrect assumptionm

Have you ever done any restorations from an image file? With Acronis you get
the option of nominating the empty space to be used for the restored image,
and the size of the resulting partition. I urge you to try this for
yourself - it will answer most if not all of your questions.

 

[Anna]

Hi Anna, thanks for the reply. But I think I'm having difficulty
getting my point across. The issue I'm getting at is not a matter of
insufficient disk space for storing the images, but that seems to be what
I am having a hard time getting across.

The issue is this:
When one restores an image of their system drive partition (C, also
included within that image I presume is the previously stored information
about the backup drive's partition size *as it was at the time that image
was taken*, which in my mind may present a problem:

Let me give a specific example. Suppose the backup drive originally has
a 100 GB partition reserved to store my system drive image backups. And
I keep saving generational images of my system drive to that 100 GB
partition. Naturally after a few backups, it fills up (keep in mind these
images are of the entire C: partition of my source drive which stores all
programs, etc. Typically the image size is around 15 GB per image).

OK, it gets full now, so I now decide to expand the backup partition size
to 150 GB to make room for more generational images. So far, so good,
and I can safely store more generational backup images.

Now suppose I decide to restore a very early system drive image, which had
been stored when the backup partition size *was recorded as being 100 GB*.

OK, that image should be restored successfully (after rebooting), I
expect - no problems so far.

BUT - now if I look at the backup drive in windows explorer, will it
appear to be only 100 GB in size (since THAT was the backup partition size
information that was originally "recorded" in its image), OR will the
backup drive correctly appear to be 150 GB (which is what it should be),
and allow thus access to all the later images? Remember, strictly
speaking, if I restore an earlier system drive image, at that time the
backup drive partition size was onlt set at 100 GB in size, so that's what
windows may now think it is, after restoring that image.

IOW, I'm assuming that restoring an image can impact partition size
information, but that may be an incorrect assumptionm

Bill:
The size of the partition on your destination HDD will not change unless you
specifically create the change through a disk management type of program.
Given your example, if the original size of that partition was 100 GB and
you later expanded the partition to 150 GB to accommodate more disk-images
(or for *any* reason), the size of that partition - now 150 GB will remain
the same regardless that you've used one of the disk-images for restoration
purposes. After all the disk-images are only files (or "archives") as
Acronis defines them, yes? The fact that you may be using (for restoration
purposes) one of those disk-images created at the time the destination
partition was 100 GB is of no consequence, i.e., it does not impact the size
of the partition that contains the disk-image file (archive).
Anna

 

[Bill in Co.]

Bill:
The size of the partition on your destination HDD will not change unless
you
specifically create the change through a disk management type of program.
Given your example, if the original size of that partition was 100 GB and
you later expanded the partition to 150 GB to accommodate more disk-images
(or for *any* reason), the size of that partition - now 150 GB will remain
the same regardless that you've used one of the disk-images for
restoration
purposes. After all the disk-images are only files (or "archives") as
Acronis defines them, yes? The fact that you may be using (for restoration
purposes) one of those disk-images created at the time the destination
partition was 100 GB is of no consequence, i.e., it does not impact the
size
of the partition that contains the disk-image file (archive).
Anna

OK, I was thinking that the partition size is saved and recorded in the
windows registry, which in turn is specified (its size) within the image
backup, so that restoring an older image would reset the apparent size of
the partition. Does that make sense?

After all, the partition size of any drive is stored as a sequence of bytes
somewhere (like in the registry, too, and THAT information was stored and
recorded in the backup image). But maybe that partition size and
allocation information is reread after rebooting (as it is reported *by BIOS
into windows*), which then overrides any recordings of size in the old
registry within the image backup.

 

[Bill in Co.]

"Bill in Co." <[email protected]> said this in news item


Have you ever done any restorations from an image file?

Very often. In fact, recently it's been weekly, due to all the tests I do.
BUT I have not changed the backup partition allocation size as I haven't run
out of room yet, but it may be getting close.

With Acronis you get
the option of nominating the empty space to be used for the restored
image,
and the size of the resulting partition.

The "empty space to be used for the restored image"? I'm restoring my
bootup drive partition (C *from* an image of that stored on my backup
drive, which is NOT changing, so that wasn't in question here.

What I *was* talking about was the (image recorded) partition size of the
backup drive after rebooting, and not the source drive, which is receiving
the restored image. The source drive partition (C is, and has remained,
fixed at 40 GB, throughout all of this. That was never in debate.

 

[Twayne]

In

Very often. In fact, recently it's been weekly, due to all the
tests I do. BUT I have not changed the backup partition allocation
size as I haven't run out of room yet, but it may be getting close.


The "empty space to be used for the restored image"? I'm restoring
my bootup drive partition (C *from* an image of that stored on my
backup drive, which is NOT changing, so that wasn't in question here.

What I *was* talking about was the (image recorded) partition size of
the backup drive after rebooting, and not the source drive, which is
receiving the restored image. The source drive partition (C is,
and has remained, fixed at 40 GB, throughout all of this. That was
never in debate.

See if this helps any:
- You can restore TO a larger sized partition on a drive.
- You can restore TO the same sized partition on a drive.
- You can NOT restore to a smaller drive than the original data occupied.
- The size of the drive holding the backups is not relevant. Anything
relevant is contained within the backups and then only concerns the drive to
restore TO.

As for whether the existing partition can be resized during the Restore,
etc., check the documentation that came with the imaging software. Some can,
some can't. Some will, some won't. Most do not. All they care about is
whether there is enough room at the destination to put all the data back. So
that drifts into whether you only backed up data or included the blank areas
of the disk in the backup. Again, program dependent; check the docs.

HTH,

Twayne

 

[Bill in Co.]

In retrospect, I think I didn't explain my thoughts very clearly in regards
to this query, and perhaps (probably?) I'm mistaken in one of my
assumptions. So, please let me restate it better, in the hopes that I can
understand this correctly:
I'll try to restate it more succinctly, as follows:

When you make an image backup of your system drive C: partition (to another
drive), also included within that stored image is information on the current
partition sizes of all your existing hard drives.

Hence, if you restore any particular system image backup, the information on
all existing partition sizes will also be restored, based on that image's
stored information about such, correct?

So, for example, if you had previously (or subsequentally) made any changes
to any drive partitions, including one used to store your image backups, and
then restored an earlier (or later) backup image, it could potentially be
problematic, since all partition sizes *would be reported just as they were
recorded when that image was made*.

But maybe this assumption is totally incorrect, and, after rebooting from
any image restore, the actual hard drive partition sizes for all drives are
properly retrieved from BIOS (after bootup), and those true values are
passed back into Windows after bootup (potentially correcting any older
stored information on partition sizes that as recorded in the restored
image).

Does that explain it better?