Partitioning question

Mayayana wrote:
The part I meant didn't make much sense was that
you're assuming any partition tool will be the same
as Acronis.

Yes, I may be guilty of that. :-) It just seemed to me that they're all
pretty similar in what they're expected to do, but I haven't checked them
all out, admitedly. I have only played around a bit with Acronis True
Image, and BootItNG (but much less so), however.

Any partitioning/imaging tool should be
able to copy a partition image to a space of equal
or greater size and should update the partition
table in the process. Resizing the new partition to fit
in the same step is something that most tools should
be able to do. Some may not. Resizing it automatically
without asking you is something no tools should do.
There's no reason to assume you want the 40 GB
backup to be resized to 60 GB.

Yes, of course. :-)

BootIt gives me the option
to choose any size up to the available space. If Acronis
doesn't offer that option you can always do it
afterward as a separate step.

OK, I was unclear in writing that.

I would first resize the partition from 40 GB to 60 GB with something like
either Norton Partition Magic 8 or the Easeus Partition Manager. Only THEN
I would make the image backup (that's preferable to me).

So, in other words, you don't have to worry about
the partition table. That's part of the software's job.
You may need to set the new partition active in order
to boot. You may also need to edit the boot.ini file
on the new partition if the position is changed. That
is, if you backed up C drive and then restored it to
a position as the second primary partition, for multi-booting,
then you'd need to update that boot.ini to point to
multi(0)disk(0)rdisk(0)partition(2) instead of
multi(0)disk(0)rdisk(0)partition(1). Otherwise, when you
boot into the second partition it will boot up the first
partition.

If I understand you correctly, you seem to be thinking
that each partition has a map of the disk and that that
map may be out of date when the partition is restored.
It doesn't work that way. Only the boot file might get mixed
up when number and placement of partitions is changed.

I'm obviously not really clear on how it all happens. But I think if I
understand this right, the partition table information is stored in the MBR
or Track 0 on the HD, and that is what has to be kept track of by the
software, and updated as necessary.

But I also thought that when an image backup of a partition was made, it
might also include information on its partition size somewhere in that
backup image file - and maybe that's an incorrect assumption.

Paul, could you clarify this for me, if you have the patience? Am I
correct in my limited understanding in what I wrote below?

Bill in Co wrote:
Paul wrote:
B00ze/Empire wrote:
On 2014-11-10 00:01, Paul wrote:

Mine has none of these features, so I wouldn't even try it.

I thought you used Macrium, which claims it has:

http://www.macrium.com/pages/features.aspx

It's not clear if the Free includes resizing partitions...

Best Regards,


As I just mentioned in another post, I would *first* resize the partition
using a separate partitioning program, and only then save the backup image,
and not use the imaging program to resize it on the fly, when it makes the
image.


It's not spelled out in as many words, but based on some of the
items, I'm guessing no, for the free version.

http://www.macrium.com/reflectfree.aspx

During a clone, it will resize the last partition if it is too
large. That's the only feature I've seen that comes close. I
don't see any interface in the "restore" for resizing.

Paul

In regards to the imaging capabilities of any imaging softwa

But it would seem to me that IF you're restoring a backup partition
image that is equal to or less than the size of the existing partition on
your hard drive, it should be able to easily do so, since it's "simply"
deleting the existing partition on your HD and directly replacing it with
an equal size or smaller size one (from the backup where the partition size
is already determined). The only difficulty I see is making sure the MBR
and partition tables are updated properly, unless I'm still missing
something (which is always possible!)

Dominique wrote:
"Bill in Co" écrivait news:I4ydnRu-
:

I'm still a bit confused over this. What happens if you restore an
image
backup when you have changed the partition size since the last image
backup?
I'm assuming the partition software will handle that without any problem,
even if its a system partition.

Here is a concrete example: You start off with C: being 40 GB, and make
an
image backup of C: Then, say, you either expand C: to 60 GB, or perhaps
add another partition D:, and now make a new image backup (which is
saved separately).

Later, you decide you want to restore the earlier setup. I'm assuming
the
partition software will readjust all the partition table stuff to
accomplish
that, and that if you had added another partition D:, it will still be
there
on the main drive.



This thread comes at the right time for me; been a long time since I've
been here and I came to ask about the same topic.

My question might be similar but reversed, I want to delete the D:
partition on a friend laptop (my friend doesn't even know there is a D:
drive on the computer and there is nothing on it but a few obscure system
folders that look like registry keys). Let's say I boot from the ATI 2009
CD and I create an image of the C: drive. After that I destroy everything
on the source drive and restore the newly created image; will it work?

TIA

Interesting thread!

I think Paul has already answered this in some detail, but to make a long
story short, and assuming you're using Windows XP and just single booting,
my expectation is that you can. But it would be prudent to have a backup
plan just in case - such as a separate clone backup of the entire drive on
another drive before trying this. (It would also be nice to know just
exactly what that stuff is on the D drive before attempting this). At any
rate, if I've missed something I'm sure someone else will step in and
correct this, but this would be my plan, and I'd only attempt it after first
having a fallback (like a clone of the drive that you know works).

Bill in Co wrote:
Paul, could you clarify this for me, if you have the patience? Am I
correct in my limited understanding in what I wrote below?

Bill in Co wrote:
Paul wrote:
B00ze/Empire wrote:
On 2014-11-10 00:01, Paul wrote:

Mine has none of these features, so I wouldn't even try it.
I thought you used Macrium, which claims it has:

http://www.macrium.com/pages/features.aspx

It's not clear if the Free includes resizing partitions...

Best Regards,


As I just mentioned in another post, I would *first* resize the partition
using a separate partitioning program, and only then save the backup image,
and not use the imaging program to resize it on the fly, when it makes the
image.

It's not spelled out in as many words, but based on some of the
items, I'm guessing no, for the free version.

http://www.macrium.com/reflectfree.aspx

During a clone, it will resize the last partition if it is too
large. That's the only feature I've seen that comes close. I
don't see any interface in the "restore" for resizing.

Paul

In regards to the imaging capabilities of any imaging softwa

But it would seem to me that IF you're restoring a backup partition
image that is equal to or less than the size of the existing partition on
your hard drive, it should be able to easily do so, since it's "simply"
deleting the existing partition on your HD and directly replacing it with
an equal size or smaller size one (from the backup where the partition size
is already determined). The only difficulty I see is making sure the MBR
and partition tables are updated properly, unless I'm still missing
something (which is always possible!)

Without delving into particulars too deeply, yes, if
something can be done with zero effort (putting restored
partition into unallocated space) then it will be done.

I'm referring to cases where normally the user would
have to use "judgment" to decide which partition
to resize, before going ahead with an operation.
The software is not a mind reader. If such a
capability exists (resize capability for virtually
any situation), there needs to be an interface
with sliders on it, to solve "tie-breaker" situations.
Maybe the user wants C: bigger and D: smaller, to dig
up enough space to fit E:. I'm sure you can see situations
where the backup/restore program is now firmly in
Partition Manager country.

I'm suggesting a conservative approach when approaching
either backup and restore or partition managers. Because
they can make a hell of a mess, given a chance. For example,
one free product, was not able to successfully resize a FAT32
partition. And who would suspect such a thing. It's not a
good thing to discover they don't really know how to
do something - the hard way. If you "think a capability
makes a lot of sense", test for it.

And if you can see controls specifically for the purpose,
that raises the odds considerably. I didn't see anything
on a restore here, that suggested I could change stuff.

As far as feature set goes, Macrium adds things on updates,
and updates are offered regularly. But I don't give permission
to the tool to update itself. I'm not actually running the
latest version. I could, but if I do that, strictly
speaking it would invalidate any testing done here. Since
they're still on the "5" stream, I would expect the .mrimg
files to continue to be compatible.

Paul

Bill in Co wrote:
Mayayana wrote:
The part I meant didn't make much sense was that
you're assuming any partition tool will be the same
as Acronis.

Yes, I may be guilty of that. :-) It just seemed to me that they're all
pretty similar in what they're expected to do, but I haven't checked them
all out, admitedly. I have only played around a bit with Acronis True
Image, and BootItNG (but much less so), however.

Any partitioning/imaging tool should be
able to copy a partition image to a space of equal
or greater size and should update the partition
table in the process. Resizing the new partition to fit
in the same step is something that most tools should
be able to do. Some may not. Resizing it automatically
without asking you is something no tools should do.
There's no reason to assume you want the 40 GB
backup to be resized to 60 GB.

Yes, of course. :-)

BootIt gives me the option
to choose any size up to the available space. If Acronis
doesn't offer that option you can always do it
afterward as a separate step.

OK, I was unclear in writing that.

I would first resize the partition from 40 GB to 60 GB with something like
either Norton Partition Magic 8 or the Easeus Partition Manager. Only THEN
I would make the image backup (that's preferable to me).

So, in other words, you don't have to worry about
the partition table. That's part of the software's job.
You may need to set the new partition active in order
to boot. You may also need to edit the boot.ini file
on the new partition if the position is changed. That
is, if you backed up C drive and then restored it to
a position as the second primary partition, for multi-booting,
then you'd need to update that boot.ini to point to
multi(0)disk(0)rdisk(0)partition(2) instead of
multi(0)disk(0)rdisk(0)partition(1). Otherwise, when you
boot into the second partition it will boot up the first
partition.

If I understand you correctly, you seem to be thinking
that each partition has a map of the disk and that that
map may be out of date when the partition is restored.
It doesn't work that way. Only the boot file might get mixed
up when number and placement of partitions is changed.

I'm obviously not really clear on how it all happens. But I think if I
understand this right, the partition table information is stored in the MBR
or Track 0 on the HD, and that is what has to be kept track of by the
software, and updated as necessary.

But I also thought that when an image backup of a partition was made, it
might also include information on its partition size somewhere in that
backup image file - and maybe that's an incorrect assumption.



There are two partition sizes, physical and logical.

Inside the file system header, is a declaration of the number
of clusters in the file system (that's the logical dimension).
The physical partition space, may be a fraction of a cluster larger.
Like, say the physical dimension is 23.7 clusters. The information
inside the file system header would say "23 clusters", and there
would be a 0.7 cluster wasted space up near the end. It would
be normal, for a newly created partition, to not have the
physical and logical dimensions match.

But the difference in dimensions can be much larger than that.
Someone attempted to use the new Windows "Shrink" capability,
which failed half way through the operation (errored out). The OS
changed the file system headers ("12 clusters"), while the MBR was
unchanged ("24 clusters"). The user noticed he was seemingly faced
with a "loss of half the disk". This is a more frequent occurrence
on Linux, because (for reasons best known to themselves), they
like to do the two resize steps separately. Such situations can be
corrected, and an example of a way, would be to run TestDisk and
have it compute a new MBR. The new MBR will "fit like a new pair
of shoes". So the "12 cluster" partition will read "12 clusters
worth" in the MBR after TestDisk. And Disk Management would then
show the proper 12 cluster remainder as "Unallocated Space".

You could even do such a thing on purpose.

Start with physical equals virtual.

+-----+------------------------+
| MBR | Partition |
+-----+------------------------+

Then edit the MBR, to make it much larger. The MBR has
the physical dimension. There is a bunch of space now,
which cannot be used. The new "physical" dimension,
prevents Disk Management from offering that space for
usage. And the file system header, prevents the file
system from going past the virtual end. Perhaps you
have, say, a complete hidden partition in there, up
near the end. Hidden from prying eyes, until you
restore certain MBR values later.

---------------- Physical -------------------
+---------------------------------------------+
+-----+------------------------+ |
| MBR | Virtual | |
+-----+------------------------+ |
+---------------------------------------------+

I've actually used techniques like that (MBR modifications),
to hide partitions while the Windows installer is being used.
As long as you know how "greedy" the tool you're using is,
that determine how safe some of these tricks are. Making
the physical and virtual a mismatch is pretty safe, because
many partitions are already that way (from birth).

Paul

of a partition was made, it
| might also include information on its partition size somewhere in that
| backup image file - and maybe that's an incorrect assumption.
|

I think so. It's possible that specific software will
mark its own disk image files, but it's not part of
the partition itself.

Dominique écrivait news:XnFA3E223C8E6F6doumdomainnet@
213.239.209.88:

"Bill in Co" écrivait news:I4ydnRu-
:

I'm still a bit confused over this. What happens if you restore an
image
backup when you have changed the partition size since the last image
backup?
I'm assuming the partition software will handle that without any
problem,
even if its a system partition.

Here is a concrete example: You start off with C: being 40 GB, and
make
an
image backup of C: Then, say, you either expand C: to 60 GB, or
perhaps
add another partition D:, and now make a new image backup (which is
saved
separately).

Later, you decide you want to restore the earlier setup. I'm assuming
the
partition software will readjust all the partition table stuff to
accomplish
that, and that if you had added another partition D:, it will still be
there
on the main drive.



This thread comes at the right time for me; been a long time since I've
been here and I came to ask about the same topic.

My question might be similar but reversed, I want to delete the D:
partition on a friend laptop (my friend doesn't even know there is a D:
drive on the computer and there is nothing on it but a few obscure
system
folders that look like registry keys). Let's say I boot from the ATI
2009
CD and I create an image of the C: drive. After that I destroy
everything
on the source drive and restore the newly created image; will it work?

TIA

Interesting thread!


Thanks Paul and Bill in Co, it's an XP computer. I will make a clone
before attempting this. There are 2 folders on the D: drive and no user
files. The actual user wouldn't know how to use the D: drive so I want to
give back all the space available on the hard disk.

Mayayana, Paul,

it might also include information on its partition size somewhere
in that backup image file

It does. The Boot Record of each logical disk (that what is actually
backupped) contains a field indicating the number of clusters/blocks on that
logical disk. From it the size of the partition can be calculated (it
needs to be just a bit bigger, for some housekeeping data and often a few
padding sectors after the logical disk).

Regards,
Rudy Wieser


-- Origional message
Mayayana schreef in berichtnieuws
...
of a partition was made, it
| might also include information on its partition size somewhere in that
| backup image file - and maybe that's an incorrect assumption.
|

I think so. It's possible that specific software will
mark its own disk image files, but it's not part of
the partition itself.

| Thanks Paul and Bill in Co, it's an XP computer. I will make a clone
| before attempting this. There are 2 folders on the D: drive and no user
| files. The actual user wouldn't know how to use the D: drive so I want to
| give back all the space available on the hard disk.

Two other thoughts:

1) Are you sure D drive isn't the
restore files? Most OEM PCs these days have an
extra partition, hidden or not, where the Windows
install files are stored, so that if C drive is lost you
can boot into the factory restore option and replace
it. If you delete that you should make a fresh disk
image first. Actually you should do that anyway.
Perhaps the most common mode of PC death is a
dying hard disk. When that happens you lose any
option to restore unless you have a disk image or
original install disk.

2) People vary in how they like to set things up,
but you might want to consider the usefulness of
extra partitions. If you get malware or some other
problem that makes C drive unbootable you'll lose
all files on that partition. If you use extra partitions
to store backups of docs, photos, etc then you
only risk losing those files if the disk drive itself
dies. Then if you lose Windows you can easily
get everything back after you reinstall. (Things like
network settings and passwords can also be stored
for retrieval in the event that C drive is lost.)

I use two hard disks with redundant storage.
I have several partitions on each that I call
Annex, Graphics, Closet, Attic, NTStorage and Back40.
Each has a separate role. Each gets backed up up
occasionally to DVDs. With that setup my only risk
of losing the data on disk is if I lose the PC itself,
through fire, theft, or maybe lightning strike. (That's
what the DVDs are for.)

Many people like a portable hard disk for backup
or main storage, but that's an extra expense that's
still vulnerable. If the disk dies, or if there's a power
surge while the disk is plugged in, that data is lost.
It's OK as a disconnected backup, but what I see is
people leaving portable drives plugged in, which is
just a waste of money.