Disaster Recovery Planning
Defining RTO and RPO, documenting recovery procedures, designing failover architecture. A written DR plan that actually works when needed.
Key highlights
- RTO and RPO definitions aligned to business needs
- Recovery procedures documented and tested
- Failover architecture design and implementation
- Annual DR plan review and updates
A backup is not a disaster recovery plan
Having backups is necessary but insufficient. a backup means you can recover your data. a disaster recovery plan means you can get your business running again quickly after a disaster. these are different. a business with backups but no DR plan can recover data but might take days or weeks to rebuild systems. a business with a good DR plan can be back online in hours.
Disaster recovery planning defines what systems matter most, how long your business can tolerate downtime, and exactly what steps to take to restore service. it's documented, tested, and regularly reviewed. when a real disaster strikes, you execute the plan instead of improvising.
Most Kenyan businesses have no DR plan
we've asked hundreds of Nairobi businesses if they have a written, tested disaster recovery plan. almost none do. they have backups (maybe). they have some vague idea of what to do if something fails. but a formal plan that's been tested? rare. this is a significant vulnerability for any business where downtime has a direct cost.
Defining RTO and RPO
Recovery Time Objective (RTO)
RTO is the maximum time you're willing to tolerate a system being down. if your email goes down and you say "we need it back within 4 hours", your RTO is 4 hours. different systems have different RTOs. for a business's primary file server, RTO might be 1 hour. for a non-critical application, RTO might be 24 hours. defining RTOs forces you to think about what truly matters.
Recovery Point Objective (RPO)
RPO is the maximum amount of data loss you're willing to accept. if your database backup runs daily and the database fails, you might lose up to 24 hours of transactions. your RPO is 24 hours. if you want to lose no more than 1 hour of data, your backup schedule must run hourly. defining RPO determines your backup frequency and strategy.
RTOs and RPOs are business decisions, not IT decisions. your IT provider helps you understand the cost of different RTO/RPO targets, but leadership decides what's acceptable for the business.
Building a disaster recovery plan
Step 1: Identify critical systems
Not every system needs the same level of protection. an email system is critical. a test environment is not. we work with your leadership to identify which systems, if down, would severely damage the business. these get the highest recovery priority. secondary systems have longer RTO windows. non-critical systems can wait.
Step 2: Design the recovery architecture
knowing what to recover is step one. having the infrastructure to recover it is step two. for critical systems, this often means redundancy. a failover site where systems can be brought up quickly, or cloud-based infrastructure that can be activated. we design the architecture that meets your RTO and RPO targets within your budget.
Step 3: Document recovery procedures
a good plan is documented. step-by-step procedures for recovering each critical system. who to contact. what to do first. what to do second. these procedures are written not for the person who knows the system (they might not be available), but for whoever needs to execute the recovery. plain language. no jargon. links to resources and runbooks. every critical system has documented recovery steps.
Step 4: Test and refine
a DR plan that's never been tested is a hope, not a plan. we conduct annual DR tests. usually simulated (not disrupting production) where we follow the procedures and see if they work. tests always find gaps. procedures that looked clear on paper are confusing in practice. resources that were supposed to be available are missing. a good test finds these gaps now, not during a real disaster.
Common disaster scenarios
Data centre failure
your server room is destroyed by fire, flood, or power failure. recovery involves booting systems from cloud backup or a secondary site. with proper planning, this is hours not days.
Ransomware attack
malware encrypts all your files and demands payment. recovery involves shutting down affected systems, isolating them from the network, restoring from backups made before infection, and identifying how the attack happened so it doesn't recur.
Key person unavailable
your IT person is ill or leaves suddenly. critical systems are down and only they know how to fix them. a good DR plan documents all critical procedures so recovery doesn't depend on one person.
Integration with Sentire's backup and recovery services
disaster recovery planning is not separate from backup. the two work together. server backup provides the data. cloud backup provides off-site redundancy. restore testing validates that backups work. and disaster recovery planning puts it all together into an executable strategy.
A plan that sits on a shelf is a plan nobody will follow
the best DR plan is one that's simple, documented in plain language, distributed to everyone who needs to know it, tested regularly, and reviewed annually. Sentire handles the technical architecture. you handle leadership decision-making about RTO and RPO. together, we build a plan that actually works.
Also in Backup & Disaster Recovery
Server Backup
On-premise server backup using Acronis or Veeam. Image-based backup with incremental scheduling and retention policies. Covers Windows Server, Linux, and hypervisors.
Cloud Backup
Off-site backup to Azure or Acronis Cloud. Ensures data survives a site disaster. Also covers Microsoft 365 which Microsoft does NOT back up natively.
Hyper-V & VMware Backup
Acronis Cyber Protect backs up Hyper-V and VMware virtual machines at the hypervisor level, agentless, incremental, and replicated off-site for complete VM-level recovery.
Restore Testing and Verification
Monthly restore tests on every backup job. Documented evidence that backups actually work. Most businesses never test until a real disaster. Sentire tests every month.
Veeam ONE, Backup Monitoring & Analytics
Veeam ONE monitors your Veeam backup infrastructure in real time, detecting job failures, forecasting storage growth, and generating compliance reports before problems become incidents.
Get it done right
Let Sentire handle your Disaster Recovery Planning.
Our engineers are based in Nairobi and support businesses across Kenya. No lengthy contracts. Just reliable, expert IT delivered as a service.