Incorrect number of backups retained and filenames corrupted

I was having this problem too. I can't see where the bug is but got around it with some experimentation. Note that the destination is irrelevant (I am emailing my backups); also, the second database backup has a corrupted date tag: [sitename]-2010-03-05T09-53-20-2010-03-05T0.mysql.gz.

It appears that you cannot use the same profile for both backups. If you create a second profile, identical to the first (different name, obviously), and specify that profile for your files backup schedule, both the database and the files backups will work. At least, that worked for me.

Hope that helps.

If you do the files manually how big is your backup? I have a 60+ MB files directory and it ran well the first time manually but cron does not like it for some reason. I think it is timing out.

Edit - Btw, I am using a remote FTP host as well.

I've seen the same thing on several sites now, and I am convinced it's a real bug, but I can't see where the fault in the code lies.

This module adds a files section to the profiles, implying that both database and files can be backed up using the same profile. You must, of course, create two schedules, one for the database and one for the files.

However, this results in two backups of the database and none of the files.

In order for it to work, you must create two separate profiles, one for the database schedule and one for the files schedule. The profiles are identical since they both contain the information for both data sources. It's an easy workaround, but not obvious.

(BTW - apart from this, it's a great module).

I hope that's clear.

I've got it now thank you very much - but no its not clear.

Its far to easy to get muddled between "schedules" and "profiles". I just assumed that a single schedule would do both files and database as specified in a single profile. Do you really need two of both? - I'm off to investigate.

Colin

A little further down the road. For me, I don't need two Profiles, but I do need two Schedules.

That seems slightly more sensible. I might be wrong, but I can't see that requirement in the docs anywhere.

Colin

Yes, you do need two schedules. I also seem to need two profiles, otherwise I just get two database backups and no files backup. I don't think I'm doing anything dumb.

This is consistent with the initial post.

I'm using Backup & Migrate 6x-2.2 and BM Files 6x-1xdev and I've no need for 2 profiles. My files are backing up OK, I've just untarred the last backup to check. So whatever this bug is, its not universal. I wasn't suggesting you were doing anything dumb, I'm just glad this bug doesn't seem to affect my setup.

Thanks for the info. I'll make sure I have all the up-to-date versions and retest.

Update: I have ensured both core and modules are the latest versions and retested. I can confirm that two schedules (one for database and one for files) pointing at the same profile results in two database backups and no files backup.

However - and this may seem obvious - the problem only occurs when both schedules are run in the same cron job. If they are staggered to run in separate cron jobs, both database and file backups are produced as expected. (Updated issue title).

Note: for some sites, staggering is not a good idea as the two backups could be out of sync.

Yes you're right, I too get two backups of the database and none of the files if they are run at the same time. I also get one of the backups with a funny name - the date and time is partly appended for a second time -

Sitename-2010-08-12T18-02-24-2010-08-12T18-02-.mysql

where it usually is

Sitename-2010-08-12T18-02-24.mysql

Colin

I'm getting the same thing except two file backups and no database backups, but I’m confident it's the same bug.

Exactly same thing, made two profiles now, will wait for next backup to see if works...

Works perfectly with 2 profiles and 2 schedules. Backs up neatly to the remote ftp of my hoster. Many thanks!

I'm pretty sure this was due to an issue in B&M which is now fixes so I'm going to mark it fixed.

I am not sure it this node would be of any help, but I just came across this, as I am getting into doing backups through the command line.

Bash scripts for backing up and copying a drupal site on linux http://drupal.org/node/886528

This is ALMOST fixed with lastest B&M updates. It now works successfully with only one profile. However, the files backup still has a doolally filename, eg: [sitename]-2010-11-17T12-42-30-2010-11-17T1.tar.gz. Very minor, I know.

Actually, it's not really fixed at all. Not only are the filenames becoming corrupted, but an incorrect number of backup files is now being retained (presumably as a result of recent B&M updates). For example, if you specify a schedule to keep 10 database backups and another to keep 10 files backups, only 10 TOTAL backups will be kept (generally 5 of each). The smallest number will always win.

Filename corruption is caused in backup_migrate.module
A timestamp is appended to Settings->filename for each run of function backup_migrate_perform_backup, causing the filename to get steadily longer.

Incorrect number of deletions is caused in schedules.inc
Files are deleted down to num_to_keep for each schedule run in function remove_expired_backups()

Whilst the filename problem can be fixed by having a one-to-one schedule->profile relationship, the deletion number problem can't.

(All the solutions I've thought of so far have disastrous knock-on effects, so suggestions appreciated)

I realise I have made a bit of a mess of this thread and there are now two issues here. Also, this concurrency problem has nothing specifically to do with Backup and Migrate Files; they are both caused by Backup and Migrate (see comment #15) and can be reproduced with that module alone.

I am therefore closing this issue (as the original problem was fixed). I have opened two new issues for Backup and Migrate (#1069286: Incorrect Number of Files Retained with multiple schedules saving to same destination directory and #1069282: Filenames "append timestamp" corruption with multiple schedules per cron run (using one profile))

I hope that's okay.