Suggested addition to documentation

Issue Summary

One common use for backup_migrate is to regularly copy the production database to a staging server, where changes and upgrades can be tested. In this case, you're likely to have two parallel Drupal directories, rather than using the multisite feature, so that you can test your site against different versions of modules and core. A time saving approach is to create a symlink from the staging backup_migrate folder to the production backup_migrate folder. That way, all backups will be saved in the same directory, and staging can easily restore from the production backups. Although the exact commands may be differnet based on your environment, they will be something like:

Further, you want to install the token module and change the backup filename to [site-url]. That way, it will be clear which backups are from which sites. If you move between staging and production a lot, I also highly recommend environment_indicator, which displays a prominent stripe on the staging server so you don't make changes on the wrong server.