Just a quick follow-up to this.

I recently discovered another problem which was contributing to this issue; there was an Internet router DNS issue which was preventing correct resolution of the Wasabi storage DNS name.

I think in the end, the problem was a combination of the sleep issue and the router DNS issue.

FYI, after quite a bit of back and forth with the support team, the outcome of this is that the issue is that I have a combination of bucket-level immutability and the 'Mark objects as deleted in a backup source' option set in my legacy backup job.

This backup option creates 'cbbdeleted' files as markers for deleted backup files and the backup software expects to be able to delete these files at any time. Being subject to the bucket-level immutability breaks this functionality.

Thanks Alexander, I've done that now.

Thanks Alexander,

I have a feature request then for the cbb command.
It would be great if the "cbb status" command had an option to list the status of any currently running jobs; preferably also returning a specific command line 'errorlevel' if any jobs were currently running.

This would provide an easily way to check for running backup jobs before executing a repository shrink via cbb.

Sorry, didn't see the responses until now.

In the end the problem was the computer going to sleep during a backup and then when waking up, freaking out because it couldn't get to the network for a few seconds.

The solution was basically under 'Options / Connection' increase the number of retries and or the time between retries to something a bit longer. I set it to 30sec in total (number of retries x time between retries).

This fixed it for the most part, although I do occasionally get the same error for some reason; but it's way better than it was.

To answer my own question; this seems like a bug, but a workaround is to disable the master password, make the enginesettings.list file changes, then re-enable the master password.

Another point to note is that immutability is only applied to full backups and additionally only those which have a specified GFS retention period set.

Another, related issue is mis-reporting of failed files; I had a couple of files blocked by antivirus (false positive), but while the backup report told me that, it showed 0 files missed:

https://i.imgur.com/DRtMpg0.png

Thanks Alexander, I appreciate the quick followup.

Thanks , I understand now.

One remaining issue however is that after I modify the enginesettings.list file as you instructed and accept the 'unauthorised changes', subsequent closing and reopening of the backup client will still show the 'unauthorised changes' dialog.

To be clear, the size on disk has been relatively constant at ~300-330GB during all backup periods shown above.

Thanks , I'll give that a go.

A question on object locking however; testing in governance mode I ran a full backup today (100% successful, no errors or warnings) with the following retention settings:


However, reviewing the resulting object locks on the resulting backup .cbl files, it shows immutability for 1 year. Given that I've specified that the December monthly should be should be kept as the yearly:


Is this because it's the first backup so it defaults to keeping that as the first yearly?

Hi ,

I don't have the history of the initial full backups to show the bloat as it progressed, but this month there was an error during the full backup and when I manually initiated one, it couldn't link to the previous generations so started again with a new generation from scratch.

This is why I noticed the big size discrepancy, given that it was backing up exactly the same files via the same backup job.

Here's the recent history & size totals:

That confirms my understanding of how the policies work in general ,

However, my main issue is the tripling of the size of the full backup. As far as I can see this shouldn't be happening. Do you have any ideas as to what might be going on here?

Just so you know, I am running daily incrementals and monthly fulls, with no intermediate weekly fulls.

Thanks ,

A few questions however:

1. There is an existing line:
<ImmutabilityMode xsi:nil="true" />

Should I leave this line as is and separately add:
<ImmutabilityMode>COMPLIANCE</ImmutabilityMode>
...or modify the existing line to be the above?


2. When I open MSP360 Backup, I get a dialog warning about 'Unauthorised Changes in configuration files. Even if I click 'Accept', I cannot run backups because they fail with an 'Unauthorised Changes Detected' error.

What is the solution to this?


3. is there anywhere in the GUI that I can confirm that Compliance Mode Immutability has been successfully enabled?

Yeah, I already did that, they told me they don't support Standalone edition anymore and to make a post here, so...