Simultaneous Scheduling Priority

[Froggie]

In relation to the above findings, for INCs, as long as the last INC string is available, even with a missing DIFF or FULL, all goes well.

Hasleo may look to determine if the entire chain is in tact (full chain integrity) before allowing a successful image... otherwise useless Incremental imaging will occur with a broken chain, unbeknownst to the user.

[Froggie]

...and when PARENT images are not available (DIFF without its FULL or INC without its previous INC chain) and errors are generated, no user LOG entries are generated.  Hard to show someone what happened...

[Gork]

Thanks. I only tried running an INC with no FULL, DIFF or prior INC available. It worked fine when the INC image backup started automatically with the schedule - though as a FULL, but threw back an error if I started the same backup scheme manually as an INC.

EDIT:
Clarification

[Gork]

I just tried testing with a DIFF without a FULL in a similar way I tested with INC. I ran a DIFF manually with no FULL and it threw out an error. But if I let it run via a SCHEULED backup it started properly, though as FULL instead of a DIFF.

EDIT:
And as with my test with INC, this is working as I would expect it to.

[Gork]

As for your other finding, that HBS reports "success" if an incremental, let's call it B INC, to an incremental, let's call it A INC (or an INC to a FULL or DIFF for that matter,) even if a prior backup in the chain is missing is definitely concerning. While technically the backup is a success based on A INC and B INC only, as an end user I want to know that B INC was not only successful, but is RESTORABLE. I want the software to verify that every file in the chain is present so a RESTORE is likely to be successful. If speed is an issue with type of a check, at least give the end user the option to have the software check the chain, with a warning present if the option to NOT check is utilized. Now that said, I haven't tested the "verify" feature to see if does indeed check the full chain.

EDIT:
added info about the option to check the chain

[admin]

As for your other finding, that HBS reports "success" if an incremental, let's call it B INC, to an incremental, let's call it A INC (or an INC to a FULL or DIFF for that matter,) even if a prior backup in the chain is missing is definitely concerning.  While technically the backup is a success based on A INC and B INC only, as an end user I want to know that B INC was not only successful, but is RESTORABLE.  I want the software to verify that every file in the chain is present so a RESTORE is likely to be successful.  If speed is an issue with type of a check, at least give the end user the option to have the software check the chain, with a warning present if the option to NOT check is utilized.  Now that said, I haven't tested the "verify" feature to see if does indeed check the full chain.
EDIT:
added info about the option to check the chain

Of course, Hasleo Backup Suite checks the backup chain before performing a new backup to ensure that the created image can be restored. However, please note that the quick image check is performed here instead of the complete image check, as the complete check checks the integrity of all the data blocks backed up, which is very time-consuming.

As for the issue you mentioned about the program not prompting an error after deleting INC B, this is because INC B is the last image in the backup chain, and deleting INC B did not result in the backup chain to be corrupted or become invalid. For example, if you have a backup chain "FULL + INC A + INC B", after deleting "INC B", "FULL + INC A" is in fact still a valid backup chain, and the next increment you perform will be generated based on INC A.

The only problem is that Hasleo Backup Suite performs a quick image check before backup, so it cannot ensure that the data blocks stored in the image files in the backup chain have not been tampered with abnormally (e.g., by a virus attack). You can choose to perform a complete image check after the backup is complete, which is of course very time-consuming.

[Gork]

I'm not referring to block level checks, I'm only referring to verifying all INC, DIFF and FULL in the chain are available for any new INC or DIFF created. When you indicate "quick image check" I can only assume that's what it's supposed to do, but unless I misunderstood what @Froggie said above - his findings indicate that it does not do that properly? I'm also not inferring that a warning that the chain would be broken should be shown if the last INC or DIFF in a FULL is deleted. I think something I said may have been misunderstood.

[admin]

I'm not referring to block level checks, I'm only referring to verifying all INC, DIFF and FULL in the chain are available for any new INC or DIFF created.  When you indicate "quick image check" I can only assume that's what it's supposed to do, but unless I misunderstood what @Froggie said above - his findings indicate that it does not do that properly?  I'm also not inferring that a warning that the chain would be broken should be shown if the last INC or DIFF in a FULL is deleted.  I think something I said may have been misunderstood.

Just deleting the last image will not cause the entire backup chain to become corrupted (regardless of whether the last image was a FULL, INC or DIFF), and HBS will continue to perform backups based on the backup chain that still exists. Note that if you perform a new full backup, the program will not check the backup chain, because a full backup does not really depend on any other backups.

If you find any problems, please let us know the steps to reproduce the problem, which can help us find and fix the problem quickly. Thanks.

[Froggie]

@Gork, I think there's a communication issue with @Admin.  Let me restate my test results, which have absolutely nothing to do with the LAST image in the chain.

I have a (6) image chain (FULL, DIFF & <4>INCs).  I remove image #4 (INC #2) then run a manual INC (#7) against that chain (which is now broken) and the INC runs successfully against the broken chain... the reason, #7's PARENT (#6) is still in place even though the chain is now broken at image #4.  As long as INCs are taken against that chain they will be successful UNTIL... a restoration is attempted to any time point in the chain.  At that point an error is indicated during the restoration concerning the broken chain.

The problem with this is that the user has no idea his image chain was ever broken, and won't find out until he needs to do a restore... which is the worst time to discover such an anomaly, at that point that knowledge is past the critical stage.  In fact, if a Partition Restore is attempted to an earlier time point in the chain that isn't broken, the user still receives a restore error... all the way back to and including the FULL.

This is not a good time to find out your chain is broken... and I don't see a reason why the software should throw an error when referencing a time point before the break in the chain.  This is what my testing has shown...

[Froggie]

When the failed RESTORATION (The image file is corrupted. <0x1779013400000005>) is done in the previous post, I don't know what criteria is used to determine the corruption.  If the Devs are just using the image chain sequence #s (there's one missing now), the same check could be made when the image is actually done, giving the user a real heads-up on the state of their imaging chain at the earliest time after the actual break in the chain.

Edit: a quick check shows that FileName sequences are NOT USED for chain integrity testing.