Virtually everybody in their right mind backs up important data once in a while. While this is good insurance against your hard drive crashing, it offers no protection against accidents which may affect your home — fire and other natural disasters and perhaps vandalism and burglary. Despite the improbability of these things, you might want to have backups somewhere other than your home, just to be on the safe side.
Though many providers offer free on-line storage, this is typically not private. Commercial providers sometimes offer online storage as part of another deal, but usually there's a catch. In my own case, my webhosting provider offers storage but deducts it from the amount of webspace I can use. On the other hand, I am allowed more than 100 e-mail accounts with 1 GB storage space each, compared to 400 MB of webspace. This is an imbalance crying for arbitrage, all the more so as it is obviously an idea designed to provide large numbers for marketing where they are unlikely to be needed. On a more general note, e-mail is recognised as private, and a provider of even a free e-mail account cannot let others access it.
The two observations above point to an obvious solution: Put unneeded mailserver space to good use by mailing backups to an e-mail account and retrieving them when needed. Since usually unfetched mail is deleted after a certain period (typically a month), this is suitable primarily for short-term backups. If you pay for your mail account, your provider may let you disable auto-deletion, and you will have a perfect backup medium. In either case, if you use it to back up code in various stages of development, you will get a version history thrown in free — e-mails are always dated, allowing you to retrieve the version from a certain date.
Still, it is cumbersome to use an e-mail client every time you want to back something up. Even worse, retrieving mails from a mail server using the usual clients will delete them, which is not what we want here. For more ease of use for e-mail backups, I wrote the Perl script mailbackup. It should be installed locally in your private bin/ directory and be readable only by you, as it is designed to contain the password verbatim. You have to fill in the e-mail address to use, the provider's IMAP and SMTP server, and the password.
mailbackup has three operation modes which are selected by the command-line switches -s (optional), -l and -r. (There are corresponding long options too.) The default mode is to save the file given by the single command line argument as the attachment of a mail sent to the given account. The name of the file is put into the mail's subject, which makes it easier to find out what has been backed up when (see below). mailbackup assumes that authentication for sending mail is performed by a previous IMAP login, which it performs itself. If your provider requires a different kind of authentification, you will have to adapt the script.
The other two modes of mailbackup are listing and retrieval. With the -l option, mailbackup lists the date, subject and size of those mails containing any of the command-line arguments in the subject. Retrieval mode is denoted by -r and a keyword and a date (best given with an abbreviated English month name to avoid confusion between day and month). The attachment of the mail which has the keyword in its subject and is from or younger than the date is retrieved from the server without deleting it. It is saved to a file name constructed from its original name and the actual date of the mail.
The IMAP protocol is used to list and retrieve mails. It allows retrieving only the mail header and having searches done by the server. If your provider supports only POP3, you are out of luck.
In addition to the command-line options telling mailbackup what to do, there is -h, which prints a brief help, and -d. The latter enables debugging mode in the Perl modules used, which then print out their conversation with the IMAP or SMTP server. This helps to solve problems and can be very instructive for getting to know these protocols.
On a more general note, and independently of its intended purpose, mailbackup can serve as an example of how to access a mail server in Perl. The module IMAP::Client was chosen over Mail::IMAPClient because it parses fetch results and returns a hash, which saves you some trouble. Unfortunately parsing bodystructure results does not work, but mailbackup does not really require that.
mailbackup is in the public domain. It comes without any warranty, express or implied. Use as is, modify at your leasure, or print out 1000 times and decorate the walls with.