Backup database
These notes from discussions among hivetool developers are posted here to aid in collaboration, to serve as a road map, and to help orient new comers to the project.
Drupal security updates
drush (https://github.com/drush-ops/drush). Requires shell access. This tool will make security updates trivial. This tool will also save you tons of time. For example, a db backup is as easy as this: drush sql-dump —result-file=../today.sql
Backups
Start with simple backup included in the hosting package. Keep an off-site backup since often the hosting backup services backup onto the same machine your hosting/db is on. Amazon S3, or even glacier, do cost, but are cheap and dependable. A cron job can rsync weekly to amazon or to our own server.
- get backups setup using the existing hosting platform. We should also document how long and how often they do backups.
- Then let’s setup syncs from these backup locations to the media server when it’s available.
I spent some time exploring our backup options:
—Netfirms— They keep a backup on a mirrored server which is available if needed. There is a charge for this if you need something restored and there is not versioning of the backups- basically whatever they have on the mirror server is what you get. Optionally, you can pay 15.00 a year for local backups, which allows you to access versioned backups for the last 30 days.
They do not offer ssh access. For me personally, this is the first question I ask hosting companies- ssh is definitely a deal breaker for me. But you are already here so, I figure we make it work.
There is a drupal module: https://secure.netfirms.com/product/site-backups/index.bml that allows you to ftp files and db via a cron job. This may be the best option for offsite backups.
—Bluehost— They provide ssh access which provides many flexible options. - You can connect like this: ssh user@website.org
- I installed drush you can view the help by typing: drush (ensure you are in the ~/public_html dir when you run this).
- I made a backup of the database using: drush sql-dump --result-file=../drush-backups/drupal.sql you can then scp to another server and to restore: drush sql-cli < drupal.sql (much easier that dealing with phpmyadmin).
- we can easily rsync files and db to the media server when it becomes available.
- It appears you must upgrade to get the backups enabled: https://my.bluehost.com/cgi/bm/product 20.00 a year- not bad as it will allow us to keep versioned offsite backups i.e. weekly, monthly, etc. It says you do get a basic backup plan, but I could not find access to this. Perhaps you have to contact them for restores and we don’t have access to rsync the backups.
—My suggestions— - pay the $15 and $20 a year for local backups at each hosting company. - when you get the media server up, we can look at rsyncing offsite backups to this. Alternatively, since the data is so small, we could use Amazon S3- it should be less than $20.00/ year for total backup storage for the two sites. - If you plan to use Drupal in the future, it’s hard to imagine without drush and ssh access. Consider moving stuff from netfirms to bluehost? This is lower priority, but something to consider down the road.
Netfirms has a way to export (the archive tool) files and the db, but this must be done manually through the control panel. But I think the drupal module (backup and migrate) would work better. We could make this work for the next year, although it’s hard to improve the responsiveness. You can try modules like boost, which convert everything to basic html pages, but if you’re showing dynamic data like the graphs, this won’t work so well.
Regarding the dynamic IP, yes we can initiate the rsyncs from the media server- good idea.
So for the offsite backups, how much would you like to store? For example, if we just sync the folders from the local backup, it’s fairly easy. For bluehost, we could sync nightly, keep backups from the last 7 days, then one for each month for the last 12 months. For a data set like this, this may be overkill and may not make sense. Any input here?
For net firms, I would setup backup and migrate to ftp, maybe weekly?, to the media server? Could do nightly, but with ftp the entire site is synced where as with rsync is will just sync the changes. We could just setup something and go from there.
