So this is definitely an ongoing issue and it happened again today.

In this case, the folder was:
C:\Users\UserName\AppData\Local\SourceServer\8569009a4bc56cb306676939718ced68f7a8a78f96079249e53de77e527951c6

Again, adding an empty file worked around the issue.

Interestingly, another, virtually identical empty folder backed up without issue:
C:\Users\UserName\AppData\Local\SourceServer\60afa13063e0486041e632ed702bf4d5e2730d5054962f7c48eda99ddb006b51

Neither folder existed in the backup destination prior to running the failing backup.

Running the latest build: 8.0.4.5

This is definitely a bug of some kind @Alexander Negrash.
I can re-create the issue.

Ok, this is weird.

I did a bit more testing and managed to 'solve' the problem by putting a file (just a blank text file) into the folder the backup was failing on, and it completed the entirety of the backup without failing...

We'll see if this continues to work correctly over the next few days...

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...