Monthly Restore Tests · Immutable Offsite Copies · Agreed RPO and RTO · Written Recovery Runbook
Backup and Disaster Recovery You Have Actually Tested
Backups exist, but nobody has proven they restore. We design your backup strategy, keep immutable offsite copies, test restores every month and lead recovery when something goes wrong.
What Are Backup and Disaster Recovery Services?
Backup and disaster recovery (BDR) services protect an application's data and keep the business running after something goes wrong. Backup is making regular, secure copies of databases, files and configuration. Disaster recovery is the tested plan and infrastructure for restoring the whole application within an agreed time after a failure, cyberattack, mistake or provider outage.
Codersarts provides backup and disaster recovery services for web applications, SaaS products, APIs and their databases. We design the backup strategy, store copies safely in a separate location, test restores every month, write the recovery runbook and lead the recovery when a real incident happens. Everything is set up in your company's own cloud accounts.
A backup you have never restored is a hope, not a plan. We prove every month that your application can come back.
Backup and Disaster Recovery at a Glance
Question | Answer |
|---|---|
What we protect | Databases, uploaded files, configuration, secrets, code and infrastructure definitions |
Where copies go | A separate region or provider, with immutable copies where supported |
Key targets | Recovery point objective (RPO) and recovery time objective (RTO), agreed in writing |
Testing | A restore test every month and a full recovery exercise at least once a year |
Threats covered | Hardware and region failures, ransomware, accidental deletion, bad deployments, account compromise |
Pricing | Set up in the Go-Live Package from $2,000; ongoing in Managed Run from $1,000 per month |
Ownership | Backups stored in accounts your company owns |
Backup vs Disaster Recovery vs Business Continuity
Term | What it means | Question it answers |
|---|---|---|
Backup | Copies of data taken on a schedule | Do we still have the data? |
Disaster recovery | Restoring systems and data after an incident | How quickly can the application work again? |
High availability | Redundant systems that keep running when one part fails | Can users avoid noticing the failure at all? |
Business continuity | How the whole business keeps operating, including people and processes | How do we keep serving customers while systems are restored? |
This service covers backup and disaster recovery for your applications, and the technical parts of your continuity plan.
RPO and RTO in Plain Language
Every recovery plan starts with two numbers, agreed with you for each application:
Recovery point objective (RPO) is how much recent data you could afford to lose. An RPO of 24 hours means a daily backup is enough; an RPO of 5 minutes needs continuous database log backups
Recovery time objective (RTO) is how long the application can be unavailable while it is restored. An RTO of one business day allows a rebuild from backups; an RTO of 15 minutes needs a standby environment ready to take over
Application type | Typical RPO | Typical RTO |
|---|---|---|
Internal tool used by a small team | 24 hours | 1 business day |
Customer-facing business application | 1 hour or less | 4 hours |
SaaS product or online store taking payments | Minutes | 1 hour or less |
Shorter targets cost more, because they need more frequent backups and more infrastructure on standby. We help you choose targets that match what an outage really costs your business.
The 3-2-1-1-0 Backup Rule
The long-established 3-2-1 rule says to keep three copies of your data, on two different types of storage, with one copy offsite. Modern guidance extends it to 3-2-1-1-0 to address ransomware:
Part | What it means | How we apply it |
|---|---|---|
3 copies | Production data plus two backups | Live database, platform snapshots and an independent offsite copy |
2 types of storage | Backups do not share a single point of failure | Database snapshots plus exported backups in object storage |
1 offsite | At least one copy in another location | A separate region, and where needed a separate provider |
1 immutable or offline | One copy that cannot be changed or deleted, even by an administrator | Object lock or write-once storage with a retention period |
0 errors | Backups are verified by restoring them | Monthly restore tests with data and application checks |
What Our Backup and Disaster Recovery Services Include
Area | What we do |
|---|---|
Backup design | Decide what to back up, how often and for how long, based on your RPO |
Database backups | Daily snapshots, point-in-time recovery where supported, logical exports |
File backups | Uploaded files and media copied to versioned, offsite object storage |
Configuration and secrets | Environment settings and infrastructure definitions stored securely and versioned |
Immutable copies | Retention locks that protect at least one copy from deletion or encryption |
Monitoring | Alerts when a backup fails, is late or is unusually small |
Restore testing | A monthly restore into an isolated environment with checks against production |
Recovery runbook | Step-by-step recovery instructions, owners and contact details |
Disaster recovery exercise | A full recovery of the application at least once a year |
Incident recovery | Leading the recovery during a real incident and reporting afterwards |
The Disasters We Plan For
Most data loss is not caused by natural disasters. Recovery plans must cover the everyday causes too.
Scenario | Example | Recovery approach |
|---|---|---|
Human error | A command deletes the wrong records or a table | Point-in-time recovery into a copy, then restore only the affected data |
Faulty deployment | A release corrupts data or breaks a migration | Roll back the code, restore data to just before the release |
Ransomware or account compromise | An attacker encrypts servers or deletes backups | Restore from immutable copies into a clean, rebuilt environment with new credentials |
Server or disk failure | A virtual machine or volume becomes unusable | Rebuild from infrastructure definitions and restore the latest backup |
Region or provider outage | A cloud region is unavailable for hours | Recover in another region from cross-region copies, if the RTO requires it |
Third-party data loss | A SaaS tool or provider loses or corrupts your data | Restore from your own independent exports |
How a Restore Test Works
A recent backup is restored into an isolated environment, never over production.
We check that the database starts, the expected tables exist and row counts match production within the expected range.
The application is started against the restored data, and key flows such as login and recent records are checked.
The time taken is recorded and compared with your RTO.
Any problem is fixed before the next test, and the result appears in your monthly report.
Restore tests regularly reveal problems that daily backup reports never show, such as missing files, expired credentials or backups that are complete but unusable.
Disaster Recovery Strategies
Strategy | How it works | Typical RTO | Relative cost |
|---|---|---|---|
Backup and restore | Rebuild infrastructure and restore data when needed | Hours to a day | Lowest |
Pilot light | A minimal copy of core systems runs in another region and scales up during recovery | Under a few hours | Moderate |
Warm standby | A smaller full copy of the application runs continuously, ready to take traffic | Minutes to an hour | Higher |
Active-active | The application runs fully in more than one location at once | Near zero | Highest |
Most small and mid-sized applications are well served by backup and restore or pilot light, combined with infrastructure that can be rebuilt quickly from code.
Recovery Runbook
Every application we protect has a written runbook, stored where you can reach it even if your main systems are down. It includes:
Who declares a disaster and who leads the recovery
Where backups are stored and how to access them
The exact steps to rebuild infrastructure and restore data, in order
How to verify the recovered application before reopening it to users
How and when to inform customers, staff and partners
Contact details for cloud providers and key suppliers
Ransomware Readiness
Attackers increasingly target backups first, so that victims cannot recover without paying. We protect against this by:
Keeping at least one backup copy immutable for a defined retention period
Storing backups under separate credentials from production, with multi-factor authentication
Alerting on unusual deletion or encryption activity
Rebuilding into a clean environment rather than restoring onto compromised servers
Rotating all credentials as part of recovery
Backup Retention and Data Protection Rules
Keeping backups forever is expensive and can conflict with privacy rules, while keeping them too briefly can leave you unable to recover from a problem noticed weeks later. We agree a retention schedule with you, for example:
Backup type | Typical retention |
|---|---|
Point-in-time database logs | 7 to 35 days |
Daily backups | 30 days |
Monthly backups | 12 months |
Immutable copies | At least 14 to 30 days, longer where regulations require |
Retention also has to respect data protection laws such as the GDPR. When a customer's data must be deleted, it will eventually age out of backups, and the runbook explains how deleted records are handled if an older backup is ever restored. Backups are encrypted at rest and in transit, and access is limited to named people.
How We Start Protecting Your Application
Inventory. We list every place your application stores data, including databases, file storage, third-party tools and configuration.
Targets. We agree RPO and RTO for each application with you.
Design and build. Backups, offsite and immutable copies and alerts are set up in your accounts.
First restore test. We prove recovery works and record how long it takes.
Runbook and routine. The recovery runbook is written, and monthly tests begin.
Who Backup and Disaster Recovery Services Are For
Businesses that have never tested a restore and want proof their data is safe
SaaS companies and online stores where downtime means lost revenue and customer trust
Companies answering security questionnaires that ask about backups, RPO, RTO and recovery testing
Teams preparing for SOC 2, ISO 27001 or cyber insurance, which expect documented and tested recovery
Apps built quickly or by AI coding tools that may have no backups at all
Backup and Disaster Recovery Pricing
Setup
Go-Live Package, starting at $2,000 one-time
Backup design, offsite and immutable copies, monitoring, a first restore test and a recovery runbook, as part of putting your application on properly managed infrastructure.
Ongoing Protection
Included in Managed Run, starting at $1,000 per month
Daily backup checks and failure alerts
Monthly restore test with results reported
Runbook kept up to date
Recovery led by our team during incidents
Standby Environments and Recovery Exercises
Pilot light and warm standby setups, and annual full recovery exercises, are estimated after review and charged at $50 per hour with your approval. Storage and standby infrastructure costs are paid directly to your cloud provider.
Add-ons
24/7 critical incident cover: $250 per month
See Go-Live and Managed Run for full details.
What Is Not Included
Backup of staff laptops, email inboxes and office files
Cloud storage and standby infrastructure charges
Physical media or tape storage
Hosting backups in Codersarts-owned accounts
Frequently Asked Questions
What is backup and disaster recovery?
Backup is making regular secure copies of your data. Disaster recovery is the tested plan and infrastructure for restoring the whole application within an agreed time after an incident.
What is the difference between RPO and RTO?
RPO is the maximum amount of recent data you could lose. RTO is the maximum time the application can be down while it is restored.
What is the 3-2-1-1-0 backup rule?
Keep three copies of data on two storage types, with one offsite, one immutable or offline, and zero errors confirmed by restore testing.
How often should backups be tested?
At least monthly for business applications, with a full disaster recovery exercise at least once a year. We test restores every month.
Can backups protect against ransomware?
Yes, when at least one copy is immutable, stored under separate credentials and restored into a clean environment.
How much do backup and disaster recovery services cost?
Setup is part of the Go-Live Package from $2,000, and ongoing protection is included in Managed Run from $1,000 per month. Storage is billed by your cloud provider.
Where are my backups stored?
In your company's own cloud account, in a separate region and where needed with a separate provider, with at least one immutable copy.
Can you recover data deleted by mistake?
Yes. With point-in-time recovery, we restore a copy of the database to just before the mistake and recover the affected records.
Prove Your Application Can Come Back
Tell us what your application does, where its data lives and how long you could afford to be offline. We will review your backups and recommend recovery targets.