Unexpected purge/re-backup behaviour

MSP360 Backup Linux Backup
1

Hi,

I’ve been using Cloudberry for a while now since CrashPlan ditched their home users.

A while back I noticed that it started re-backing up everything for what looked like no reason. I upgraded to the latest version and (possibly coincidentally) the problem went away.

Yesterday it started again. Going through the logs, it looks like Cloudberry decided to purge the majority of the backup from the cloud storage and then the next day it realised the backup was missing the files and re-uploaded. There have been no changes to the file locally.

Retention is set pretty conservatively - delete 90 days after deleted from local host and keep 5 versions of a file as it changes but that’s it.

Any idea why I’m seeing this behaviour?

I like Cloudberry but random purging and re-backing up a few days later is not good…

Thanks,
Keith

2

[reply=“Keith;d369”] What storage provider do you use? In case of S3 the first thing to check is if you have any bucket-side Lifecycle rules set up.

3

Quick response - Thanks Matt.

I am using S3 but there aren’t any lifecycle rules setup on the bucket. I’m assuming no lifecycle rules means nothing ever expires.

The purge logs I mentioned are a large number of these:
2018-07-30 06:00:11,384460 [INFO ]: [ CBB ] [ 4 ] Purge file success, path:

It reads as CBB choosing to purge the file rather than S3 expiring it but I could be wrong.

4

Hi [reply=“Keith;1251”], there was a bug in Backup v 2.4.* where under specific conditions all versions of files were purged even if it contradicted the retention policy.
We have fixed it in Backup v 2.5, now retention policy works correctly.
Please upgrade to the latest available version.
Sorry for the inconvenience!

5

Thanks Caleb - I am indeed running a 2.4 iteration at the moment. I’ll take a look at the 2.5 upgrade.

Where do you publish full release notes? I’ve never been a fan of always upgrade to the latest just because it’s there - while bug fixes and security fixes will usually drive the upgrade (rather than new features) the question of how quickly still depends on what they are.

6

[reply=“Keith;1253”] there’s a thread about it somewhere here on the forum. It’s not the full list, just the most interesting things - the full list for 2.5.0 would contain over 150 items, most of them don’t deserve your attention.

7

[reply=“Keith;1253”] For 2.5 the post is this one : Link

8

Thanks for the help guys. 2.5 installed so fingers crossed.

I’m not sure on the lifecycle/dev environment you develop with that might make it easier but seeing various comments around use of CloudBerry Backup in business environments you may be surprised on the number of people interest in full release notes.

9

So far so good on the purge/backup behaviour - no repeats since installing 2.5.

That said, it’s become VERY memory hungry - currently chewing up over 10GB of memory in idle state:

keith@here ~ $ free -m
              total        used        free      shared  buff/cache   available
Mem:          15998       14998         186          98         813         527
Swap:         15623          10       15613
keith@here ~ $ ps -aux | grep Cloud
root      1540  0.4 31.1 6852820 5099088 ?     Sl   Aug05  71:37 /opt/local/CloudBerry Backup/raw_bin/cbbWebAccess
root      1546  0.1 31.1 5946832 5103884 ?     Sl   Aug05  31:49 /opt/local/CloudBerry Backup/raw_bin/cbbLocalManagement
keith    12773  1.2  0.4 602484 75600 ?        Sl   08:44   0:00 /opt/local/CloudBerry Backup/raw_bin/cbbGUI
keith    12905  0.0  0.0  14228  1088 pts/1    S+   08:45   0:00 grep --color=auto Cloud

Swappiness is set to pretty much disable it (never been a fan of an SSD being hit hard as a result of bad memory management) so I’m guessing if I were to go digging it would be CloudBerry that’s triggered the swap too.

Is this something that’s already on the radar to be fixed? Can the background processes be forcibly reset by the CLI to release that memory?

Thanks,
Keith

10

[reply=“Keith;1429”], do you use 2.5.0.32? Because there was a memory leak bug in that version, so we published v2.5.0.39 that has it fixed.
If you get this with a 2.5.0.39 - this requires additional investigation. Please send the diagnostics (./cbb sendLog), it will open a Support ticket right away.

You might also want to restart the service to lower the memory consumption (at least at first). The command is either

  • sudo systemctl restart cloudberry-backup
    or
  • sudo service cloudberry-backup restart
    depending on your distro.
11

[reply=“Gleb;1431”]
Thanks Gleb - it is indeed .32. I saw there was a .39 but no indications of what was in it when I looked earlier (since fixed with your note on the .32 release notes).

I’ll get .39 running and let you know if the problem continues.

12

[reply=“Keith;1434”] true that, I’ve updated the release notes.