If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Disk imaging and restore question (again)
I may have mentioned this before, but I want to use a specific example to
make sure I have this down right: C = 40 GB, D = 40 GB (and my C is almost full now) I also have two backup images of each partition on another drive: Let's call them bakC1 and bakD1 for the two respective image backups. Let's say I now change my source drive to: C = 50 GB, D = 30 GB (since my C was getting full) Now if I understand this correctly, *if* I were to restore bakC1 (40 GB) for some reason, there should be no problem, since the source drive has 50 GB reserved for C now anyway (with 30 GB adjacent to that reserved for D). BUT if I instead were to restore bakD1, there *would* be a huge problem (since the first 50 GB on the source drive now stores C, and there is only a 30 GB adjacent physical segment left to accommodate the 40 GB. So my guess is most imaging programs would fail at that attempt. Note: Implicit in all of this is my assumption that normally when you restore an image back to the source drive, nothing is relocated or moved on the source drive to make room for this, which would be way too time consuming. Rather, the original existing partition is simply marked as deleted, and the new one takes its place in the same physical area of the disk. (That way there is no time consuming relocation of any existing data to make additional room for anything - like having to move any existing partition data out of the way). It may depend on the imaging program, but I'm guessing this is standard practice. Is this correct? |
Ads |
#2
|
|||
|
|||
Disk imaging and restore question (again) - addendum
Ooops, I forgot to add that immediately following the C and D partitions
are the 40 GB E: and 40 GB F: partitions, so there is no adjacent free or unallocated space anywhere in there (only way at the end of the drive, which is a 250 GB drive) |
#3
|
|||
|
|||
Disk imaging and restore question (again)
| It may depend on the imaging program,
Yes. And you didn't mention the imaging program. So how can anyone else know what can be done? Whatever the program is, your options should be explained in the directions. If not then why not just try doing it with a dummy partition? I use BootIt, which I think allows me to resize while restoring, to any size = data size and = empty space where partition will be created. But I don't think the older version of BootIt did that. As I recall the image had to be written as it had been created, then any resizing would be a separate step. In other words, this is not a question about laws of physics. It's a question about your software, and we don't even know what your software is! Didn't you ask this weeks ago? Have you actually been sitting around for weeks wondering whether you can do what you want? You could easily do a test run in an hour or so. |
#4
|
|||
|
|||
Disk imaging and restore question (again)
Mayayana wrote:
It may depend on the imaging program, Yes. And you didn't mention the imaging program. So how can anyone else know what can be done? Whatever the program is, your options should be explained in the directions. If not then why not just try doing it with a dummy partition? I'm using ATI. I haven't found *this* particular query answered in their docs, but I may be missing it. I use BootIt, which I think allows me to resize while restoring, to any size = data size and = empty space where partition will be created. I'm assuming that is as long as it does NOT require *moving* any existing partition data - that is, iff there is sufficient free space, no problemo. Then resizing shouldn't be a problem. Otherwise it has the potential to be a Big problem due to the overhead of requiring moving existing partition data to another region of the hard drive, a very time consuming process. So even with BootIt (Bing), I'm not sure you know for sure. But I don't think the older version of BootIt did that. As I recall the image had to be written as it had been created, then any resizing would be a separate step. In other words, this is not a question about laws of physics. It's a question about your software, and we don't even know what your software is! Didn't you ask this weeks ago? Have you actually been sitting around for weeks wondering whether you can do what you want? You could easily do a test run in an hour or so. I asked something related to this before (some senility on my part, perhaps) |
#5
|
|||
|
|||
Disk imaging and restore question (again) - addendum
Bill,
So, you have 160 GB allocated outof 250. In that case the most simple answer (depends on how you look at it ofcourse :-) ) would be to create a new 40GB partition at the end, and than backup F, restore into G, backup E, restore into F, backup D, restore into E (in effect bubbeling D thru F one spot up), delete D. At that moment you 1) have a 40 GB empty spot directly following C, allowing you to extend it, 2) all partitions still have their current driveletters, 3) all old old backups can be restored. Regards, Rudy Wieser -- Origional message: Bill in Co schreef in berichtnieuws ... Ooops, I forgot to add that immediately following the C and D partitions are the 40 GB E: and 40 GB F: partitions, so there is no adjacent free or unallocated space anywhere in there (only way at the end of the drive, which is a 250 GB drive) |
#6
|
|||
|
|||
Disk imaging and restore question (again)
| I'm using ATI.
I've never heard of that. | I'm assuming that is as long as it does NOT require *moving* any existing | partition data - that is, iff there is sufficient free space, no problemo. | Then resizing shouldn't be a problem. Otherwise it has the potential to be | a Big problem due to the overhead of requiring moving existing partition | data to another region of the hard drive, a very time consuming process. So | even with BootIt (Bing), I'm not sure you know for sure. | Obviously there has to be sufficient free space! Say you've got a 40 GB partition with, say, 38 GB of data. I understood yout question to be whether you can restore that into free space that's at least 38 GB and perhaps as big as 50 GB. There's no program that's going to move your files around to make a partition fit. You can't restore a 40 GB partition as a 60 GB partition if you only have 50 GB free space. Is that really what you're wondering about? Or maybe I've misunderstood. |
#7
|
|||
|
|||
Disk imaging and restore question (again)
My apologies, it seems I hadn't explained myself very clearly.
I am aware (courtesy of Paul) that when restoring a partition from an image backup, *some* programs will allow you an option on resizing at that point, assuming there is enough *adjacent unallocated space* next to it. But that's not the specific issue I'm asking about. My question was more specific: Do any imaging programs offer that capability of resizing (during an image restore operation) *IF it would require moving any other adjacent data partitions out of the way to make room for it (assuming, of course, there is still sufficient unallocated space somewhere in the drive - typically near the end of the drive). Note: if any imaging programs (like ATI = Acronis True Image) or Bing do allow for this, this would become a very time consuming operation, using the example I mentioned, before the restore operation could ever be completed. I don't think this specific issue was ever answered, but maybe I'm getting a bit senile. My apologies if this was getting old, or I've forgotten something. |
#8
|
|||
|
|||
Disk imaging and restore question (again)
Bill in Co wrote:
My apologies, it seems I hadn't explained myself very clearly. I am aware (courtesy of Paul) that when restoring a partition from an image backup, *some* programs will allow you an option on resizing at that point, assuming there is enough *adjacent unallocated space* next to it. But that's not the specific issue I'm asking about. My question was more specific: Do any imaging programs offer that capability of resizing (during an image restore operation) *IF it would require moving any other adjacent data partitions out of the way to make room for it (assuming, of course, there is still sufficient unallocated space somewhere in the drive - typically near the end of the drive). Note: if any imaging programs (like ATI = Acronis True Image) or Bing do allow for this, this would become a very time consuming operation, using the example I mentioned, before the restore operation could ever be completed. I don't think this specific issue was ever answered, but maybe I'm getting a bit senile. My apologies if this was getting old, or I've forgotten something. http://www.macrium.com/help/v5/How_t...nd_Reorder.htm https://kb.acronis.com/content/2770 ******* They also support random access by mounting the .mrimg as a virtual disk. I think ATI does this too. Paul |
#9
|
|||
|
|||
Disk imaging and restore question (again)
Thanks, Paul. Those articles both talked about resizing options during the
restore operation, but they also seem to imply (to me) that you'd better have some adjacent unallocated disk space if the partition size needs to be enlarged to accept the backup image, at least as I read it. IOW, movement of other previously existing and adjacent partition data out of the way to make room for it is not an option (and perhaps that's expecting too much for an imaging program). Is that what you get out of it? Paul wrote: Bill in Co wrote: My apologies, it seems I hadn't explained myself very clearly. I am aware (courtesy of Paul) that when restoring a partition from an image backup, *some* programs will allow you an option on resizing at that point, assuming there is enough *adjacent unallocated space* next to it. But that's not the specific issue I'm asking about. My question was more specific: Do any imaging programs offer that capability of resizing (during an image restore operation) *IF it would require moving any other adjacent data partitions out of the way to make room for it (assuming, of course, there is still sufficient unallocated space somewhere in the drive - typically near the end of the drive). Note: if any imaging programs (like ATI = Acronis True Image) or Bing do allow for this, this would become a very time consuming operation, using the example I mentioned, before the restore operation could ever be completed. I don't think this specific issue was ever answered, but maybe I'm getting a bit senile. My apologies if this was getting old, or I've forgotten something. http://www.macrium.com/help/v5/How_t...nd_Reorder.htm https://kb.acronis.com/content/2770 ******* They also support random access by mounting the .mrimg as a virtual disk. I think ATI does this too. Paul |
#10
|
|||
|
|||
Disk imaging and restore question (again)
Bill in Co wrote:
Thanks, Paul. Those articles both talked about resizing options during the restore operation, but they also seem to imply (to me) that you'd better have some adjacent unallocated disk space if the partition size needs to be enlarged to accept the backup image, at least as I read it. IOW, movement of other previously existing and adjacent partition data out of the way to make room for it is not an option (and perhaps that's expecting too much for an imaging program). Is that what you get out of it? You'd better carefully test that. There is a tick box for "MBR". If the MBR gets overwritten on a restore, you're in serious trouble. If the MBR box is unticked, I don't see a problem restoring a partition to an unallocated space. You then have to decide whether the tool wants a partition as a target to overwrite, or whether it will simply grab a partition table entry and restore to that. (Slot 4 not used, it restores to slot 4.) And if the tool does that, if it knows the source partition contains an OS and is active or the like, it's going to realize that boot.ini or the BCD, will no longer be correct. Partition Magic used to solve this, by taking OS partitions and carefully putting them into the correct partition table slot on the destination, to make the boot.ini correct. Rather than automatically editing the file and just fixing it. This can have consequences, because it sometimes results in the partition table not being in spatial order. The OS doesn't care about this, but the user certainly cares, when they have to perform mental gymnastics when looking at Disk Management. I put up with that for a year on a disk here, before biting the bullet and fixing the boot.ini myself, then swapping the two partition table entries around with ptedit32. Fixed. So on the one hand, you can test that restoring with MBR tick box unticked, works. And there are no side effects. You might test with a data partition, restoring a data partition to the disk and see if the regular boot OS still boots. That would be evidence the MBR wasn't badly treated. But the worst case would be, the MBR gets overwritten with an old MBR (partition table setup). Then, you'll need to immediately use "TestDisk" before it's too late and the partitions are overwritten and corrupted. ******* Now I think you understand why I recommend leaving the damn partitions alone, and restoring "like to like". No thinking required. No testing required. Nobody gets hurt. Etc. I've left my main drive here, in "fixed partition mode" for the last year, so all my backups are still valid. If you want to avoid trouble, just restore to an empty disk. Nobody can get hurt that way... You can always use a Partition Management product after that point, to copy/move the partition where ever you want. The destination MBR then is likely to be treated with a bit more respect. So if there is a mismatch between the thing to be restored, and the final target, do the operation in two steps. Even if it takes longer, there is less hair loss. Having a tick box for the MBR is kinda crappy, because it leaves a lot to the imagination as to what is going to happen. I had the same problem with Partition Magic. I innocently moved an OS from one disk to the other. It took a while, until one day I was looking at Disk Management, and something wasn't making sense. That's when I noticed the move of the OS, was done at the expense of screwing around with the partition table, something I would not have predicted at the time. This is all part of "testing" or "dialing in" crappy software. Sometimes you get an immediate rude surprise (system no longer boots), or only much later you discover subtle damage. The way this was done, wasn't deadly, but it did make me just a bit angry. Even if a dialog had popped up and said "OK if I juggle your partition table a little bit?", I would at least have been warned. Paul |
Thread Tools | |
Display Modes | |
|
|