send e-mail with backup attached

that's not a bad idea, i can see it being a problem with larger sites though. I'll keep it on the todo list, but I think backup to remote server is a higher priority for right now.

As a small improvement to this I think, since it's working with Workflow-ng, you can create an action to send an email with the link to the Backup.

+ 1 on this.

Would be great, means clients can have the system email the DB off to a gmail account. Free offsite storage!!

+1.

Even better, the emails may have different interval than scheduled backups so that you can, for example, do onsite backup once a week but email the latest backup once a month.

Lots of good ideas here. Sounds like this think could be it's own module. I think my next steps should be to make sure I the hooks to Backup and Migrate that could make this possible.

+1

+1

I've been looking into ways to do this but haven't found one yet.

I like the idea of this feature, but I'm still concerned about:

1) Sending large files via email (some of my sites have >20 meg backups even compressed, that will choke a lot of email systems in my experience)
2) Sending unencrypted database dumps over insecure email.

I think perhaps the best way to handle this still would be to open up the appropriate hooks in backup and migrate, so that someone with more email experience than me can implement such a module (with AES integration too, perhaps - http://drupal.org/project/aes)

Ronan

@Leontius Adhika... - that's an interesting idea but IMO not worth the extra clutter in the UI.

@ronan #10
1) True. This isn't a perfect solution for large sites but most sites are not large. For most sites this is a reasonable way to get their backup data.
2) Currently most people download the backup via browser, right? Which means that most people are downloading it via http (instead of https) so it is not being sent "unencrypted". Ditto for anyone getting it via ftp. I'd say that the bigger problem is that the backup is then being stored on a mail server which is often not very secure. So if you use this...be sure to secure your mail server ;) Perhaps we should add a note about that to the README.txt?

I need this feature for 6.x. I used to use the dba module but feel that backup_migrate is more specifically suited to my needs (backing up my database). So, I copied the major bits of code from the dba module (which I've used successfully for months) and added it to backup_migrate. I didn't follow the backup_migrate coding style because it doesn't follow core. I followed core style as closely as I remember it.

It worked in my initial testing and I'll be leaving it live on two sites.

So, this broke the "download a file now" functionality. Download a file now takes a variable from _backup_migrate_dump_tables and redirects to it. Previously that function didn't return anything. Now that it's returning the filename...that functionality is screwed up.

Attached patch "fixes the glitch" by removing the $out and the form redirect from that _submit function. It also fixes an old notice related to missing quotes on site_name and the undefined $encode variable in the new _mail_backup() function.

@lennart, @a_c_m, @txcrew, @silverwing - can you test/review this patch to help us make sure it works under a variety of conditions?

One other thought I've had is about the "how many scheduled backups to keep" field. I'd rather not have those on my server and prefer to just have them emailed. The best I can do with the current set of controls is keep 1 copy on the server.

I think perhaps that the best way to handle this is to make "0" copies to keep really mean "0" as in - don't do it. Then if people want to keep them they can just set the number really really high. We could also use "-1" to mean "don't do it" which is more backwards compatible if a little weird to the end user. We could also make a checkbox for "don't save any". Thoughts? Should we try to change that in this issue?

I'd like to keep it as simple (and backward compatible) as possible since long term I'd like email to be just one more backup destination in a more flexible system at which point, no copy would be kept on the server if you chose email as your destinations for scheduled backups.

To that end the '-1' works for me (with perhaps a javascript-y checkbox to pre-fill that value and hide the text box to make it more user friendly)

looks like it, but the latest version of each branch are very similar, it might apply to the 5 branch.

Here is a re-roll with the -1 system to never keep files.

@ronan - I'd love to hear any thoughts you have on how to improve this or what it needs to be worthy of getting committed. Also, I'm not sure where the javascript from your comment in #15 is actually supposed to do, but if you can elaborate I'll happily add it.

@greggles,

Sorry I haven't responded to this. I've been working on a version 2 of the module which refactors the destination handling code to make other destination types (like email) easier to implement with a plugin system. I'm pretty close to having code I can share on that, but unfortunately am now tied up with work and may not have a chance to finish it until this weekend.

Once I do I'll refactor your patch to become the email destination plugin.

I'm not going to commit this to the 1.x branch itself because I'd like that branch to be feature stable so I can support it for stability etc.

Thanks again for this patch, and I'll keep you posted when the new version with email functionality is in the repo.

Ah, ok. Thanks for the update. I can happily wait until the next version.

This is now an option in version 2.0. Help testing this would be appreciated. It is greggles' code (thanks greggles) refactored to work with the new destination system. It was working great when I refactored it first, but isn't working on my local today, so I suspect my laptop is having issues sending mail. I'll push it to a different server later and try and confirm these suspicions.

Other user's experiences with this are welcome.

@Ronan - great news, thanks for your work on this module. I'll try to test it shortly.

In development I often use the Devel module and then set it to "log e-mail only" (on admin/settings/devel ) so that all mails are sent to watchdog instead of a mail server. Helps test this situation where a laptop can't send mail and also makes sure you don't accidentally send notifications from a test/dev server.

bacuptomail.php
Script to send files same type from dir to email.
1. Put bacuptomail.php to drupal dir
2. Set same vars:

//$dir="files/backup_migrate/manual/";
$dir="files/backup_migrate/scheduled/";
$ext="gz";
$content_type="application/x-gzip";
$maxsize=10000000;
...
$mail->from     = "info@mysite.com"; 
$mail->to     = "mail@gmail.com"; 
...

3. Run by cron.

bacuptomail.php

Thanks for sharing the script Dimm. I hope other people fond it helpful while I'm working on adding file backup support. I'm marking this ticket as closed again, since this is not actually a patch and there's no way for me to apply it to the module.

Thanks again.
Ronan

this doesn't work anymore in drupal 6.20, any suggestions?

subsribe

I am also not able to send email in drupal 6.20