Since we seem to have a little bit of momentum and I mentioned backups, I thought I would toss out what I typically do/use to backup any production sites.
Please feel free to add comments or questions... Perhaps if I get a chance, I will also write up how I typically test/play on a development server before deploying any module updates and how I periodically sync the dev server with the live site so that I have up-to-date live content to test with.
Here goes... sure I missed a few minor details but at least its a starting point
PHP limits:
As your database grows, you may want to up the values for the upload_max_filesize (16M +). You, may even need to boost up the max_execution_time or memory_limit variables past the defaults. I've had to changed these on a few machines from the defaults of 30 seconds/64M to 180 seconds / 128-256M respectively. I believe the development module can add some time/memory usage information on the footer but I typically do not turn this on at the production site. Drupal let's you enforce lower limits and I mainly have needed these when I do either a restore (via phpAdmin) or an import from the backup/restore module during refresh of a development server with production data.
Automated database backup via Backup and Migrate Module:
Configured two near-identical profiles to backup database weekly. Both are to FTP accounts with one account being on the same server and the second being my server at home. Currently only use unique (and unknown to public) username/passwords for protection but will hopefully get a chance to turn on the AES encryption module later. This is mainly to capture snapshots of the database on machines that do not have heavy use. I would suggest a more frequent schedule if you have much more traffic.
Typically back everything up except for the following tables: cache, cache_*, ctools_*_cache, search_dataset, search_index, search_total, sessions, and watchdog.
Set to save only the last '8' (two months) backups but seems not to delete old backups beyond '8'. Probably an FTP access issue on my side and not the module. I have plenty of disk space, so I just do manual cleanups about once a quarter of old backup files.
Have 'lock tables during backup' enabled for both. If your DB grows large and you have slow access to any offline server, you may wish to change this. The backup's run off periodic cron runs and you cannot always guarantee that they will run at a specific time. Wish they would add that so that they would trigger during an off hour. Anyone have an idea on how to work around this issue?
Luckily never had an offsite server failure and needed to recover. All my DB failures have been my fault (usually an unstable module) and I had done full manual DB and directory backup before attempting the module install/upgrade. I will be moving my own offsite servers to the same hosting service that I use for the other sites I use, so I might just point another FTP backup there. Their base service does not have any data transfer or storage limits like my soon-to-be old provider.
Manual database and file backups (download offsite files to local machine and then backup locally):
I typically do this every month or so and always before updating any new modules or upgrading the drupal version. I even do it on my development machine before testing new modules or hacking on any PHP code. The directions below are what I usually do on a production machine but the steps are identical for a development machine. (And you will probably get pretty good with 'restoring' on your development machine over time).
Use BeyondCompare 3 (BC3) as a file comparison and transfer utility and is available on both Windows and Linux. Inexpensive and very much worth the price. It is very easy to use, good file exclusion and comparison filter capabilities, read-only comparison 'sides', and supports FTP sites as a base directory. BC3 also remembers past search sessions and you can rename them so it is easy to kick off a download (update) session.
If you have the Views Module:
Create a User Notice content type that is composed of a Body and a Display Date/Time field. Set the Display Date/Time field as hidden in the Manage Display tab so that it is not visible to the typical viewer. The date/time field should have a start and end time enabled. Disable comments, XML sitemap inclusion, Printer/Email/PDF checkboxes, and so on.
Create a User Notice views block. Set it to show any published User Notice content with a display 'start' time >= 'now' and 'end' time <= 'now'. That way you can set it up ahead of time and should you forget to actually do it, it will hide itself later.
Put the User Notice views block near the top of you main page.
Create an instance of the User Notice content type to inform the user of when the site will be under maintenance and may be unavailable. Keep it unpublished until you want to schedule a maintenance window. Once you actually finish, you can always unpublish it manually instead of waiting for the 'end' time to come. When you do finish, do not delete, just edit it again the next time you do maintenance.
To perform the backup:
Start up BC3. The first time you will need to manually set up what files to use and exclude. On the left side, select the FTP base directory where your drupal install is. Set this side to 'read-only'. Set the right side to be a directory on your local machine.
For files to exclude, these will be unique (or none at all) depending on your site setup. Typically you will be excluding whole directory trees. I typically disable the at_css, color, ctools, js, styles, simpletest, and xmlsitemap directories under the .../sites/default/files directory. You may not have all these or maybe a different set depending on your modules installed. You can usually tell by the content of the directories under sites/default/files as to whether or not you save them.
During the maintenance window (or even just a little before it), open the BC3 session and it will start to enumerate both sides. This can take a little while but after the first few seconds, it should have the first level done. Select Edit -> Select All and then Actions -> Compare Contents. This step could take a few minutes (or even an hour or more) depending on your site's size and your connection speed.
Note that you site is not yet in maintenance mode... Once the initial comparison is complete, replicate any changes from the left directory over to the right directory. Keep the session up even after it completes !
Now that the initial replication is done, log into your drupal server and enable maintenance mode (and stay logged in yourself). Once in maintenance mode, go over to your BC3 session and select Edit -> Full Refresh. This will begin to refresh both sides of the comparison and since you did not close down your previous comparison session, it will know that the left-hand side if is is not larger (or newer) than the last time it compared the file, it should be the same. Any modifications, additions, or deletions will be detected during this phase.
While the refresh is going on, backup your database to your local machine. Most hosting platforms have phpAdmin installed. If you host your own production server, look into adding phpAdmin to manage your mySQL database if you do not have it already. I typically choose the Advance export method and specify just the drupal database (and enable compression). Save this to somewhere on your machine and give it a unique name that includes what it is and the date the backup occurred.
Once the BC3 full refresh completes (usually quite fast), resolve/replicate any changes and then 'zip/tar' up your backed up files and store it in the same location as your database backup.
Turn off maintenance mode on your server.
Should you ever have to restore the backup, remember to log into the drupal server on your browser before restoring the files and database since you were in maintenance mode when you did the backup. Once you finish the restore and have done a cursory check of your site, remember to turn off maintenance mode.