Feature Request: Build in check to Rapid Recovery to avoid a new base image on every dirty reboot

There are multiple reasons for base image creations, many of them unrelated to bad shutdowns. Basically there are 3 categories of issues conucive of base images all related to the so called change logs (located in the System Volume Information of each volume):

1. The change logs are not updated while there are blocks changed on the volume (most common case a system crash)

2. The change logs cannot be read (common issue -- anti virus locking the change logs)

3. The amount of change on the volume is more than the Agent can process (the rule of thumb is 40% on a good size volume but there are many other factors, like system load).

There is always the possibility that the change logs get corrupted but this happens rarely -- i.e. the change logs are locked long enough that the changed volume blocks are lost -- this may be the result of AV or some other third party software.

In my opinion, the ideal for getting read of unwanted base images would be a new operation -- let's call it rolldown that would compare the base image with the data already present in the repository and transform it into an incremental. Other option that nay be of interest would be agent side deduplication.

There are multiple reasons for base image creations, many of them unrelated to bad shutdowns. Basically there are 3 categories of issues conucive of base images all related to the so called change logs (located in the System Volume Information of each volume):

1. The change logs are not updated while there are blocks changed on the volume (most common case a system crash)

2. The change logs cannot be read (common issue -- anti virus locking the change logs)

3. The amount of change on the volume is more than the Agent can process (the rule of thumb is 40% on a good size volume but there are many other factors, like system load).

There is always the possibility that the change logs get corrupted but this happens rarely -- i.e. the change logs are locked long enough that the changed volume blocks are lost -- this may be the result of AV or some other third party software.

In my opinion, the ideal for getting read of unwanted base images would be a new operation -- let's call it rolldown that would compare the base image with the data already present in the repository and transform it into an incremental. Other option that nay be of interest would be agent side deduplication.