[BUG] Retention not working on Backup

[fresent]

Describe the bug

We have a local daily backup (full) scheduled for 3 days. The local backup system doesn't honor the retention policy, and keeps growing.

We ran into disk full and found, backups with over 60 days. We have cyberpanel installations with version 2.0 to 2.2 and issue is happening on all of them.

[Dreamer41]

Maybe first try update latest 2.3 version before send bug report.. Your versions are many months old.

[fresent]

That's a fair point.

We did went through changelog list to see, if a fix related to this was introduced there before logging a bug report. However, with projects like this, its common that not everything might go in change log.

After your reply, we re-checked our installations and found it's indeed replicating on one of our test node as well with below version,

Current Version : 2.3 Build : 1Current Commit : d3256678becae4aa4ecebb5f3efe6cf087df3904 Latest Version : 2.3 Latest Build : 2Latest Commit : d617e48d37b9f7bb65ffa6a23547bd8a9a99853e

Just upgraded one of our test node to latest commit, will wait for current daily cycle of 3 days and report if the issue still persist.

[hadi060]

I also published a post on the forum about this issue for months now without answer, I don't know why. I noticed that there is another topic, maybe more. Hope they fix it as soon as possible.

[fresent]

Can confirm now, the issue still persist in current version.

Backup retention days are not honored and backups keep accumulating till disk get full.

[snawaze]

Still not working.

[Dreamer41]

It's highly recommend update all your servers with cyberpanel to latest 2.3. There was some serious security issues too on previous version what 2.3 patched.

On Fri, Jul 29, 2022, 13:18 Fresent @.***> wrote:

That's a fair point.

We did went through changelog list to see, if a fix related to this was introduced there before logging a bug report. However, with projects like this, its common that not everything might go in change log.

After your reply, went back to re-check version and found it's indeed replicating on one of our test node as well with below version,

Current Version : 2.3 Build : 1Current Commit : d325667 https://github.com/usmannasir/cyberpanel/commit/d3256678becae4aa4ecebb5f3efe6cf087df3904 Latest Version : 2.3 Latest Build : 2Latest Commit : d617e48 https://github.com/usmannasir/cyberpanel/commit/d617e48d37b9f7bb65ffa6a23547bd8a9a99853e

Just upgraded one of our test node to current latest commit, will wait for current daily cycle of 3 days and report if anything issue still persist.

— Reply to this email directly, view it on GitHub https://github.com/usmannasir/cyberpanel/issues/938#issuecomment-1198920332, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZOH5EPHF22KGRJ5P72M673VWNZSFANCNFSM545LHFXQ . You are receiving this because you commented.Message ID: @.***>

[broiniac]

@fresent I can confirm that this bug is still present.

Current Version:  2.3
Build:  2
Current Commit:  bb6d095a5362deccf8166759ce69d8576eafc7c7

I will perform CyberPanel to 2.3 - commit 53ca589b8a6c6db32b7c19730ced15c7f2647215 and report in couple of days. Looking at changelog and pull requests I can't find any, even remotely related commits being merged though.

[broiniac]

As expected based on commit history - retention is not working.

There are 5 columns in /backup/scheduleBackup Last Run | All Sites | Frequency (<Period>) | Retention (<Period>) | Current Status Retention column value is Not running. Changing anything in Frequency column (there is a select box) displays red, error flash message with Operation Failed! 'backupRetention' text.

Any alternative using CyberPanel with working backup retention at this time, or I should rather go for custom shell scripts?

[broiniac]

For anyone waiting for this one to be fixed - simplest workaround would be to use cron job. For example:

0 3 * * * find /home/backup/ -type d -mtime +5 -exec rm -r {} \; >/dev/null 2>&1

Will run: 0 3 * * * - daily at 3:00 am find /home/backup - search /home/backup directory recursively -type d - for directories only -mtime +5 - older then 5 days -exec - and run on them… rm -r {} - … command rm -r <directory> \; - separately for each directory >/dev/null 2>&1 - discard any potential output