Scheduled Manual FULL Image after Disk Geometry Change

[chmichael]

Well it might better to separate Disk & Partition backups.
In my case i have a System Disk © and a Data Disk (D).

System backup doesn't allow me to select the Data Disk.

[admin]

Well it might better to separate Disk & Partition backups.
In my case i have a System Disk © and a Data Disk (D).

System backup doesn't allow me to select the Data Disk.

We are considering how to better address these issues and will improve them in future versions.

[admin]

...and in the current implementation, the user is not evened warned that partitions in their image are no longer being imaged... a very large surprise when it comes to needed restoration at some point (the restore will probably die due to no OS or RE partition being in the image at the time of restoration, as in the example mentioned).

If any partition is changed, Hasleo Backup Suite will prompt "Specified partition not found," so the situation you mentioned will not occur. Especially for existing system backups, when a partition is changed, HBS V5.4.2.3 will automatically re-select the changed partition, so there won't be a situation where Windows fails to start after restoration.

[Froggie]

I think you missed my point.  I understand that your current approach to SYSTEM images (fixed in v5.4.2.3) is somewhat adequate for that issue, but it is not adequate for those users primarily using DISK/PARTITION imaging.

I, like many other users, know what partitions we need for a successful reBOOT.  As a result, I use DISK/PARTITION imaging to include my needed System partitions as well as other important partitions contained on that same disk.  The added function in v5.4.2.3 DOES NOT WORK for DISK/PARTITION imaging.  The result of that failure is/can be as follows...

When using TASK-based imaging, the imaging operation (any image type, scheduled or manual) does not inform the user that they no longer have certain partitions being imaged that were originally in the task spec.  Any attempted recovery operation WILL NOT recover any previously changed partition geometry... why, because they no longer exist in the images being taken since the geometry change.  What's worse, if a user's RETENTION spec removes the only versions of those geometrically changed partitions, the user has no previous references to their originally changed partitions, ie, dead in the water.

Since the most important partition on the System, the OS partition, occasionally gets changed by MicroSloth due to space needs on updating Windows Recovery partitions, without notice to the user by the way... this turns out to be a recipe for disaster, especially for those who rely on set'n'forget task imaging.

I don't know what type of partition geometry checking you are doing, but it needs to be improved very soon.  Other major imaging apps, Macrium REFLECT being the somewhat gold standard, do exactly what's expected here.  They detect a geometry change in whatever type of image is being done and force a new FULL image, restarting the imaging chain with the new geometry... the only real flaw here is their app doesn't tell the user of that fact, they just discover it along the way  .  You should do the same thing with, hopefully, a user notice 

[al3x]

Since the most important partition on the System, the OS partition, occasionally gets changed by Microsoft due to space needs on updating Windows Recovery partitions, without notice to the user by the way... this turns out to be a recipe for disaster, especially for those who rely on set'n'forget task imaging.

That's an interesting point I'd like to pick up on. The last time the RE partition got resized/rebuild I received the error "Specified partition not found" and was notified by this error (see here). So at least if a partition is removed and rebuilt this will trigger an error and the user won't end up with missing backups.

And then there's you who reported that the partitions were left out silently(?) after changing geometry, no errors whatsoever.

Now I'm wondering: When does the backup job report errors and when will it silently continue without some of the partitions?

[JayDee]

I think you missed my point.  I understand that your current approach to SYSTEM images (fixed in v5.4.2.3) is somewhat adequate for that issue, but it is not adequate for those users primarily using DISK/PARTITION imaging.

I, like many other users, know what partitions we need for a successful reBOOT.  As a result, I use DISK/PARTITION imaging to include my needed System partitions as well as other important partitions contained on that same disk.  The added function in v5.4.2.3 DOES NOT WORK for DISK/PARTITION imaging.  The result of that failure is/can be as follows...

When using TASK-based imaging, the imaging operation (any image type, scheduled or manual) does not inform the user that they no longer have certain partitions being imaged that were originally in the task spec.  Any attempted recovery operation WILL NOT recover any previously changed partition geometry... why, because they no longer exist in the images being taken since the geometry change.  What's worse, if a user's RETENTION spec removes the only versions of those geometrically changed partitions, the user has no previous references to their originally changed partitions, ie, dead in the water.

Since the most important partition on the System, the OS partition, occasionally gets changed by MicroSloth due to space needs on updating Windows Recovery partitions, without notice to the user by the way... this turns out to be a recipe for disaster, especially for those who rely on set'n'forget task imaging.

I don't know what type of partition geometry checking you are doing, but it needs to be improved very soon.  Other major imaging apps, Macrium REFLECT being the somewhat gold standard, do exactly what's expected here.  They detect a geometry change in whatever type of image is being done and force a new FULL image, restarting the imaging chain with the new geometry... the only real flaw here is their app doesn't tell the user of that fact, they just discover it along the way  .  You should do the same thing with, hopefully, a user notice 

Just so I can understand... if there's a geometry change 5.4.2.3 will initiate a full backup but not necessarily all the previously specified partitions?
So, at the moment, I would need to create a new backup task instead?

JayDee

[Froggie]

The Geometry change causes any task-based image to drop the modified partitions, not just a full... and this is for a Disk/Partition backup only.  The same problem with a System backup was fixed in v5.4.2.3.

As of now... yes, the only way to capture the complete geometry partition change in a Disk/Partition backup is to initiate a brand new task.

[al3x]

As of now... yes, the only way to capture the complete geometry partition change in a Disk/Partition backup is to initiate a brand new task.[/size]

You can also just edit the task and reselect missing partitions. No need to recreate the whole task.

Btw, I tried to recreate your scenario where you change partition layouts and rerun the task. This always triggers an error message for me, I'm still wondering how you managed to "lose" partitions without any error messages. Did you maybe edit the task and saved it without re-checking the lost partitions?

[admin]

As of now... yes, the only way to capture the complete geometry partition change in a Disk/Partition backup is to initiate a brand new task.[/size]

You can also just edit the task and reselect missing partitions. No need to recreate the whole task.

Btw, I tried to recreate your scenario where you change partition layouts and rerun the task. This always triggers an error message for me, I'm still wondering how you managed to "lose" partitions without any error messages. Did you maybe edit the task and saved it without re-checking the lost partitions?

@Froggie If any partition changes occur, the program should prompt an error message. I'm also very curious to know how you managed to "lose" partitions without any error messages?

[Froggie]

If the msg was via NOTIFICATIONS... I have that turned off due to the image startup/end notifications that are a bit of a pain to me all the time (I do lots of IntraDaily imaging).  If it's a process error window... it never showed up.

I will turn NOTIFICATIONS back on for HBS and see what happens.