RPO and RTO in plain terms
NIST defines the recovery point objective as the point in time to which data must be recovered after an outage. For a course site, ask: if the site died right now, how much recent activity could we afford to lose? New sign-ups, lesson completions, quiz results, forum posts and orders are the data at risk.
NIST's recovery time objective is the overall length of time a system's components can be in the recovery phase before the outage starts to damage the business. For a course site, ask: how long can students be locked out before refunds, chargebacks or a failed launch follow?
The two numbers are independent. A site can have an hourly backup but take a day to restore because nobody knows the steps, or restore in 30 minutes from a backup that is a week old. The plan has to address both.
What your host's schedule means for your RPO
Your backup frequency is the floor for your RPO. These are the published options at three managed hosts.
| Option | Backup frequency | Worst-case data loss | Published cost |
|---|---|---|---|
| Kinsta, WP Engine or SiteGround default | Daily | Up to about 24 hours | Included |
| Kinsta 6-hourly backup add-on | Every 6 hours, kept 24 hours | Up to about 6 hours | $20 per site per month |
| Kinsta hourly backup add-on | Every hour, kept 24 hours | Up to about 1 hour | $100 per site per month |
| SiteGround Premium backups | Hourly for the past 48 hours, on a best-effort basis | Up to about 1 hour, when on schedule | Not priced in SiteGround's backup article |
| Manual backup before risky changes | On demand | Only what happens during the change | Included: Kinsta keeps up to 5; SiteGround gives 5 slots on GrowBig and higher; WP Engine checkpoints on demand |
Setting targets for a course business
Illustrative example, not real data: a site enrolls about 40 students a day and takes most payments through Stripe. With daily backups, losing the database at 18:00 could mean losing up to a day of enrollments. Payments are still recorded at the processor, so the loss is recoverable, but someone has to match each payment to a student account and restore access by hand. If that takes five minutes per student, 40 students is over three hours of work on top of the restore.
That arithmetic is how you choose. If the daily rebuild work is acceptable, keep the daily backup and write the reconciliation steps into the plan. If it is not, a 6-hourly add-on at $20 a month cuts the worst case to about 10 students in this example. For RTO, a solo creator might accept four hours outside launch weeks and one hour during a launch, and then has to prove in a drill that the restore can meet it.
Write the targets as sentences: We accept losing up to 24 hours of data outside launches and 6 hours during launches. We aim to have students logging in within 4 hours, and within 1 hour during launches.
The one-page plan
| Field | What to write | Example |
|---|---|---|
| Incident lead | One person who decides the site is down and starts the plan; one backup person | Owner; contractor as backup |
| Contacts | Host support route and account ID, registrar, DNS provider, payment processor, email provider, developer | Host chat plus ticket, registrar support page |
| Credentials location | Name of the password manager vault, never the passwords themselves | Shared vault called Site recovery, two members |
| Backup locations | Host backups, offsite bucket, last manual download | Host daily, weekly bucket copy, monthly drive |
| RPO and RTO | The two sentences you agreed | 24h and 4h normally; 6h and 1h at launch |
| Restore order | Numbered list, below | Access, DNS, hosting, database, files, payments, email |
| Student message | A short prewritten notice and where it is posted | Email list tool and social profile |
| Last drill | Date, backup age, time to restore | Date, 14 hours, 2 hours 10 minutes |
Restore order
- Access: confirm you can log in to the registrar, DNS provider, host, payment processor and email provider. If an account is compromised, regain it and rotate passwords and keys first.
- DNS and domain: check the domain has not expired and the records still point where they should.
- Hosting: confirm the hosting account and server are available, or start a replacement from your offsite copy.
- Database and files: restore files first and then the database, which is the order WordPress's documentation gives, unless your host restores both together.
- Payments: check that payment webhooks reach the site and that keys are the live keys you expect.
- Reconcile the gap: list payments and sign-ups since the backup and restore each student's access.
- Email: send a test password reset and receipt to confirm transactional email works.
- Tell students: post the prewritten message, then a short all-clear.
Where credentials go, and where they do not
The plan should say where credentials are, not what they are. A one-page plan gets printed, emailed and saved in shared folders; passwords in it leak with it. Keep them in a password manager vault that at least two trusted people can open, including the registrar login, two-factor recovery codes, the host login, the backup storage keys and the payment processor's dashboard.
Store the offsite backup credentials separately from the site. If an attacker gets into WordPress or the host account, they should not also find the keys that delete your offsite backups.
Test it, then trust it
WordPress's documentation recommends keeping at least three, ideally five, recent backups and occasionally making a manual backup to make sure the process is working. Go further than that and restore one. Twice a year, and before a big launch, restore the latest backup to a staging site or a local copy, time each step and write down the backup's age and the time it took. Those measured numbers replace the targets you guessed.
If the drill misses the target, change one thing: a more frequent backup to improve RPO, or a better-written restore order, a second trained person or an offsite copy that is quicker to fetch to improve RTO.
Questions before you decide
What is the difference between RPO and RTO?
RPO is the point in time your data must be recoverable to, which sets how much recent data you could lose. RTO is how long recovery can take before the outage harms the business. NIST SP 800-34 defines both.
What RPO do I get with managed WordPress hosting by default?
Kinsta, WP Engine and SiteGround all take daily backups by default, so the worst case is losing up to about a day of data. Kinsta sells 6-hourly backups for $20 and hourly backups for $100 per site per month.
Should passwords go in the disaster recovery plan?
No. Name the password manager vault and who can open it. A plan document gets shared and printed, so any credentials written in it are exposed along with it.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- NIST CSRC glossary: Recovery point objective (SP 800-34 Rev. 1) Accessed 30 Oct 2026
- NIST CSRC glossary: Recovery time objective (SP 800-34 Rev. 1) Accessed 30 Oct 2026
- Kinsta: Backups Accessed 30 Oct 2026
- WP Engine: Backup and restore Accessed 30 Oct 2026
- SiteGround: Backup service Accessed 30 Oct 2026
- WordPress Developer Resources: WordPress backups Accessed 30 Oct 2026
- US-CERT (CISA): Data Backup Options Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.