If your GreenArrow server is hosted by GreenArrow, then both the daily, and monthly backups described on this page are taken.
If your GreenArrow server is not hosted by GreenArrow, you have the option of purchasing a managed backup service from GreenArrow, which includes the service described in this document’s Daily Backups section only.
$100/month/server for up to 50GB of backup space when measured after running the command below.
Restoration of Backups
- Normal Business hours - $100/hour with a 3-hour minimum charge. Additional time is rounded to the nearest quarter-hour.
- If Support Staff is available - Outside Normal Business hours - $150/hour with a 3-hour minimum charge. Additional time is rounded to the nearest quarter-hour.
Backups are made to an offsite Google Cloud Persistent Disk once a day. A snapshot of this disk is taken following the daily backups. Snapshots are stored in a different data center than hosted GreenArrow installations reside in.
Backups are retained for the following periods:
- All backups are retained for 7 days.
- One set of backups per week are retained for at least 31 days.
The data that’s backed up daily includes:
- GreenArrow Engine’s and Studio’s applications.
- GreenArrow Engine’s and Studio’s statistics.
- GreenArrow Engine’s and Studio’s PostgreSQL database.
The data that’s backed up daily does not include:
- The operating system that GreenArrow Engine was installed on.
- Messages that are in GreenArrow Engine’s mail queue.
- Bounces that haven’t yet been processed.
Daily backups contain the data needed to restore a GreenArrow server to normal operations following most failure scenarios. If a failure occurs that’s significant enough to render your GreenArrow server unbootable, there are three common recovery scenarios:
- Hosted customers will have their most recent monthly backup restored, then have the most recent daily backup imported.
- Non-hosted customers who maintain their own image-based backup system can restore their most recent image-based backup. The most recent daily backup can then be imported.
- Non-hosted customers who do not maintain their own image-based backup system will need to have GreenArrow software re-installed. Following the reinstall, the most recent daily backup can be imported.
If the nature of the failure that’s being recovered from renders the most recent daily backup incomplete, a previous day’s backup can be restored in its place. For example, if a failure occurs while a daily backup is in progress, then the most recent backup would be incomplete, and the previous backup should be restored instead.
Daily managed backups have the following requirements that non-hosted customers should keep in mind when managing their server:
Sufficient disk space to hold the files that are generated by the backup server is needed. Backups will usually occupy less space that the value returned by the command below. Contact GreenArrow technical support if you’d like a more accurate estimate of disk space requirements:
du -Lhs --exclude="qmail-disk/queue" --exclude="qmail-ram/queue" --exclude="qmail-bounce/queue" --exclude="maildata/Maildir-bounce" /var/hvmail/
- If a firewall is being used, it should allow incoming SSH connections from
- If the SSH server is listening on a non-default port , notify GreenArrow so that the backup server’s SSH client configuration can be updated.
backups.drh.netserver should be able to SSH into the GreenArrow server. See the SSH Access page for details.
Hosted customers each have their own virtual machine, which can be moved between physical servers within GreenArrow’s hosted environment.
Monthly, image based backups of these virtual machines are taken. These images are uploaded to Amazon’s S3 Storage Service, where they are stored in a different data center than your GreenArrow server resides in.
The 2 most recent monthly backups are retained on S3. The most recently monthly backup is also retained on local storage, so that it can be restored from directly when possible. We store image based backups in both places, because local storage is faster to restore from than S3, but S3 is more reliable than local storage.
RAID is used so that the failure of a single hard drive won’t cause downtime for hosted customers.
ECC (Error-Correcting Code) RAM is used to detect and correct common memory errors.
Redundant host servers are maintained on site, so that if a failure occurs that does render a physical server inoperable, any impacted customers can have their virtual machines moved onto a redundant server.
Each host server has two (redundant) power supplies, which are plugged into independent power circuits being fed from independent power sources.