Most Valuable Professional
Group: Forum Members
Thanks Nick! I would recommend that a new backup set be created if encryption is enabled and the existing backups are unencrypted. Just updating the log to say, "Encryption specified but not enabled because the existing set is unencrypted" would certainly be better than the current state -- and I would argue that would be the best choice for handling changes to the compression setting -- but if the user never looked at those log entries, they could still end up without encrypted backups they thought they were getting, potentially forever in the Incrementals Forever case. I feel the mind set should be, "If the definition file specifies encryption, then under no circumstances should Reflect generate an unencrypted backup."
For cases where the encryption simply changes (as opposed to being newly introduced), I can see the virtue of both responses. Automatically creating a new Full would be convenient for cases where the password change was deliberate. However, if the password change was the result of accidental or malicious direct modification of the XML file, then automatically creating a new Full would mean Reflect would now be creating backups that the user would not be able to decrypt later, which the user might not discover until they had to restore something. The current failure behavior instead potentially gives them a warning about this problem upfront, although not if the first backup after the accidental/malicious change was a Full, I suppose, or even in the case above where encryption is newly added. If MIG's protection against modification/deletion by non-Macrium applications were extended to definition files, I would say that creating a new Full automatically would be the way to go.