Scheduled Backup Fails to Delete Old FIles and Folders

Hi,

Old backups not being deleted.

Not files, not directories.

Disk fills, further backups fail.

Happens with SSH (to Linux, Centos 5) or local backups.

For local backups, I have pre and post commands to mount and dismount the backup filesystem.

See attached screen cap showing settings.

Thanks,

G

Status: 
Closed (fixed)

Comments

Could you post the output of ls -l run in the incremental directory on the remote SSH server? I'd like to see what timestamps are on the sub-directories.

Also, does the wwwbackup user have full SSH access to the remote system, or is he limited to an scponly shell?

Hi Jamie,

The SSH user is chrooted (/home/e-smith/files/ibays/nobackup/files) with a BASH shell...not root nor with sudo permissions.

I have since deleted all of the backups so that tonight's weekly backup will pass, but I had run the 'ls' command before deletion and the history was still on my screen.

They all seem properly timestamped, though the permissions should include group write ideally (for me). I just noticed that...but it shouldn't affect this issue.

Anything older than 6 days should have been deleted...at least that was my intention. Ultimately, I'd like to have a local backup with 1 full and 6 days incremental retention (due to limited local disk space) and the remote backup with a month or longer retention.

[root@linus ~]# ll /home/e-smith/files/ibays/nobackup/files/WWW_Backup/*
/home/e-smith/files/ibays/nobackup/files/WWW_Backup/full:
total 28
drwxr-sr-x 2 wwwbackup shared 12288 Sep  4 03:50 03-09-2012
drwxr-sr-x 2 wwwbackup shared 12288 Sep  9 15:39 09-09-2012
drwxr-sr-x 2 wwwbackup shared  4096 Sep 16 00:09 16-09-2012

/home/e-smith/files/ibays/nobackup/files/WWW_Backup/incremental:
total 44
drwxr-sr-x 2 wwwbackup shared 4096 Sep 10 01:14 10-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 11 00:54 11-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 12 00:48 12-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 13 00:42 13-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 14 00:59 14-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 15 00:50 15-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 17 00:10 17-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 18 00:10 18-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 19 00:09 19-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 20 00:09 20-09-2012
drwxr-sr-x 2 wwwbackup shared 4096 Sep 21 00:10 21-09-2012

Thanks again,

G

That ls output looks a little odd .. the dates certainly aren't in the format Virtualmin normally expects. Normally I would expect a format like :

-rw------- 1 root root 1837704 2012-09-16 03:17 wpmu.home.tar.gz
-rw-r--r-- 1 root root    6749 2012-09-16 03:19 wpmu.home.tar.gz.dom
-rw-r--r-- 1 root root     124 2012-09-16 03:19 wpmu.home.tar.gz.info
-rw------- 1 root root 3194172 2012-09-16 03:13 wpmu.webminrubytest.com.tar.gz
-rw-r--r-- 1 root root    6826 2012-09-16 03:19 wpmu.webminrubytest.com.tar.gz.dom
-rw-r--r-- 1 root root     162 2012-09-16 03:19 wpmu.webminrubytest.com.tar.gz.info

Do you have some custom ls options or non-english locale or language set?

Hi again,

On CentOS/Redhat, 'll' is aliased to 'ls -l --color=tty'.

What your software uses, I have no idea.

On Debian/Ubuntu, I generally use 'ls -al' or 'ls -aln' if I want numeric user/group IDs.

It all depends on the switches...

G

Virtualmin just uses ls -l to get the directory listing.

Is the remote system configured to use a different locale, rather than US english? That could be effecting the format of dates in the directory listing ..

No. US English.

Just now, I have tweaked the fstab settings to automount the backup filesystem and I'll tweak the scheduled backup job not to mount/dismount the filesytem to see if that makes things better.

I have deleted all old backups and I'm manually running the full backup job since today is Sunday, the normally scheduled full backup day.

Two suggestions:

1) When you manually fire off a scheduled backup job, it doesn't run the pre/post scripts. It should.

2) Leaving a backup filesystem unmounted unless actually performing a backup is a commonly accepted practice. Your scheduled backup procedure should support that.

Thanks,

G

I was wrong about the order of the purging - it actually happens before the post-backup command is run. So in your case, a scheduled backup should cleanup old directories before un-mounting. Also, the date format on those directories should be fine..

I would be glad to login to your system myself to see what is going wrong here..

BTW, it is a misfeature that pre and post backup commands are not run when you trigger a scheduled backup manually via the UI. I will fix that in the next release.

Hi Jamie,

To be clear, the issue was 'fixed' by leaving the backup disk mounted at all times.

I look forward to the next release, as always.

Thanks,

G

Ok, marking this as fixed then.

Automatically closed -- issue fixed for 2 weeks with no activity.