Backups remain in tmp directory when chosen to download

I have a similar problem:
backups get accumulated in files/tmp directory, though I always chose to download them!
I am able to delete them manually via FTP, but this doesn't look like the way it should be.
There are also other old files in that directory, mostly images. Aren't they supposed to be deleted at cron run?

same problem here. When I backup the database through this module and download this to local ,
there still will be a file in /tmp folder.
This is not very secure is it?

Any solutions?

Can everybody confirm that they are actually using the 2.2 version of the module. This was an issue in an earlier version which was fixed some time ago, so if it's cropping up again in the latest version I'd like to get that taken care of.

I have 6x.2.2 installed

Generally speaking B&M should be deleting tmp files after it is done executing. Occasionally it will not be able to (if the script times out before it gets a chance for example). In that case it should be checking your tmp directory for leftover files and deleting them during cron.

If neither of these things is happening you may be having some sort of server error during the delete. It could be a file permission thing, it could be a php timeout or memory limit. Check your apache logs for php errors if this kind. Try doing a local backup to see if there are any errors (the errors don't show when you download because the page doesn't refresh).

As for the security: B&M has to store the backup files to the server for at least some period, even when it's working correctly so if you don't trust your /tmp directory (if you're on a shared host for example) then you definitely should specify another temp directory in your drupal file settings. You should just make sure that the temp directory is not inside your webroot.

Let me know if this points you guys in the right direction.

I can confirm this happened to me on one site, with version 2.4. (Changing version number on ticket.)

I had one scheduled job as a daily backup to the local designated directory, keeping 21 backups max. However, I found about 50 backups for each day in the tmp folder in the files directory. The module's schedule display indicates that the task was never run. Not one of the backups made it to the scheduled backup directory configured. I confirmed that the apache has appropriate permissions to write to that folder.

dblog reveals that cron was indeed failing to complete, so perhaps that is the issue and cleanup never happened. If I can take the time, I'll dig for more info on this.

ronan> Generally speaking B&M should be deleting tmp files after it is done executing. Occasionally it will not be able to (if the script times out before it gets a chance for example).

Q1: If Destination = Download, should I expect the temp files to be deleted after they are created and sent to the client? In my experience they are not deleted until the next cron run. I think this is normal...?

Q2: During a cron run when should backup_migrate/includes/files.inc be getting included? During the bootstrap in backup_migrate_cron()?

In the case of an Aegir-managed site (which I do not expect the B&M developers to support any differently than a normal drupal site) I notice that file removal fails during a cron run at this point:

function backup_migrate_cleanup() {
  // Check that the cleanup function exists. If it doesn't then we probably didn't create any files to be cleaned up.
  if (function_exists('_backup_migrate_temp_files_delete')) {
    _backup_migrate_temp_files_delete();
  }
}

That function_exists returns FALSE. I can "fix" this problem with something like this:

*************** function backup_migrate_cron() {
*** 151,156 ****
--- 151,159 ----
    _backup_migrate_message_callback('_backup_migrate_message_log');
  
    backup_migrate_include('schedules');
+   if (!function_exists('_backup_migrate_temp_files_delete')) {
+     include_once './' . drupal_get_path('module', 'backup_migrate') . "/includes/files.inc";
+   }  
    backup_migrate_schedules_run();
  }

but I'd love to understand where includes/files.inc is supposed to be getting included when the cron hook is invoked? Is it during the bootstrap in backup_migrate_cron()?

Q3. What is the thinking behind the 6 hours added to $expire in _backup_migrate_temp_files_delete()? This seems kinda long, but maybe we are trying to catch this scenario:

- user is on a slow connection
- they backup a lot of data maybe with no compression (maybe they are using backup_migrate_files and there are big media files)
- since the download takes forever we don't want to delete the file before the user is done downloading.

This makes sense, but the flip side of it could be that the user makes numerous uncompressed backups and fills up their disk within a 6 hour period. Not sure I have a better solution, just want to understand the intention here.

Reopen this if it's still an issue in the latest versions.