Analytical use of cookies
Business continuity
Backup and disaster recovery for business
Backup is not Disaster Recovery. A resilient design defines business priorities, RPO and RTO, retention, separate fault and administration domains, restore ownership, acceptance tests and a documented return to normal operations.
Define RPO and RTO by workload
RPO defines acceptable data loss and RTO defines acceptable service recovery time. ERP, databases, mail, files and archives can require different objectives and restore sequences.
Separate fault and access domains
A useful copy must survive the incident affecting production. Location, storage, credentials, retention and immutability should prevent one failure or compromised account from reaching every copy.
Use layered copies
A practical model combines fast local recovery, a separate repository, an off-site copy and, when required, an immutable or offline layer and a second-site recovery target.
Test restore, not only backup jobs
Successful job status does not prove recoverability. Databases, mail, files, applications, configuration, certificates, DNS and user access should be restored and accepted in a controlled test.
Write the DR runbook
The plan should cover incident declaration, isolation, infrastructure recovery, application order, traffic switching, business validation, communications and failback.
Assign owners and evidence
The customer and operator should know who approves priorities, application consistency, retention, restore execution and acceptance. Every test should leave a dated result and corrective actions.
Supported environments
Backup and DR platform matrix
The service can cover virtual, physical and application workloads, but it is not sold as one universal template. Compatibility, repository design, retention, immutability, encryption, RPO/RTO, restore performance, test frequency and SLA are confirmed for the actual environment in the offer and agreement.
VMware
Protection path: Image-level backup, an off-site repository and Veeam Cloud Connect where the platform version and licensing are compatible.
Qualification: Confirm VM inventory, change rate, application consistency, retention, restore network and test frequency.
Microsoft Hyper-V
Protection path: Host- or VM-level protection, a separate repository and Veeam Cloud Connect where the selected release and licence permit it.
Qualification: Confirm cluster topology, volumes, application-aware processing, credentials, networking and recovery order.
Proxmox VE
Protection path: The protection path is selected after checking the Proxmox version, storage, guest systems and required recovery granularity.
Qualification: Confirm whether the design uses native, agent, image or file-level copies and how an isolated restore will be tested.
Physical systems, databases and files
Protection path: Agent-, application- or file-aware protection for physical servers, endpoints, mail, databases, ERP, file services and business applications.
Qualification: Confirm data consistency, credentials, transaction-log handling, dependencies and business acceptance tests.
Depending on the design, the repository layer can use Veeam Cloud Connect, off-site storage or Multiserver NAS with S3, NFS and SMB access. Monitoring, restore tests, reporting and 24/7 NOC/SOC support are included where defined in the agreed service scope.
Recovery objectives
RPO/RTO decision matrix
The ranges below are design examples, not a public service guarantee. Exact objectives depend on workload consistency, data volume, dependencies, recovery capacity and tests, and are confirmed in an individual offer and agreement.
Archive and reporting
Examples: Documents, exports, historical reports
RPO: Hours to one day
RTO: Hours to the next working day
Typical design: Scheduled off-site copy with retention and a documented file-level restore
Standard business systems
Examples: Files, collaboration, internal applications
RPO: Example target: 1-4 hours
RTO: Example target: 4-8 hours
Typical design: Frequent backup, separate repository, off-site copy and periodic restore test
Transactional workloads
Examples: ERP, CRM, e-commerce, databases and mail
RPO: Example target: 15-60 minutes
RTO: Example target: 1-4 hours
Typical design: Application-consistent copies, separate credentials, tested database and application start order
Critical services
Examples: Systems whose outage immediately stops key operations
RPO: Minutes or near-zero after validation
RTO: Minutes to one hour after validation
Typical design: Replication or frequent copies, second-site capacity, automated monitoring, documented runbook and regular exercises
Five protection layers and fault domains
1. Production
Primary systems and data. This layer is not a backup and defines the first fault domain.
2. Fast local recovery
Snapshots or a nearby copy shorten common restores, but they can share power, storage or administrative risk with production.
3. Separate repository
Dedicated capacity with its own retention, monitoring and controlled restore access.
4. Off-site and immutable layer
A copy separated by location and credentials, optionally immutable or offline, protects against site failure and destructive account compromise.
5. Recovery target
Cold, warm or active capacity in a second fault domain is selected according to the validated RTO and dependency map.
Disaster Recovery runbook: from incident to failback
1. Detect and declare
Confirm impact, incident owner, communications path and the decision to start recovery.
2. Isolate the cause
Contain compromised credentials, ransomware, failed storage or network faults before connecting protected copies.
3. Restore infrastructure
Prepare compute, storage, network, firewall, identity, DNS and certificate dependencies.
4. Restore data and applications
Recover in dependency order and record the timestamp of the restored data set.
5. Switch and validate
Change traffic only after technical tests and business acceptance of critical transactions.
6. Communicate and monitor
Track service state, queues, integrations, performance and user reports throughout recovery.
7. Fail back and improve
Approve return to the normal platform, preserve evidence and update the runbook with lessons learned.
Responsibility matrix
Business priorities and acceptable loss
Owner: Customer business owner
Required output: Approved service classes, RPO/RTO and recovery order
Application consistency and dependencies
Owner: Customer application owner with DataHouse
Required output: Backup method, quiescing, credentials and application start order
Repository, retention and monitoring
Owner: DataHouse within the agreed service scope
Required output: Capacity, copy jobs, alerts, access separation and retention policy
Recovery execution
Owner: Named technical teams in the runbook
Required output: Restore steps, escalation contacts, access and evidence log
Acceptance and failback
Owner: Customer business owner with DataHouse
Required output: Acceptance result, open defects, traffic decision and return plan
Evidence from a restore test
- test date, tested workload and responsible people;
- selected restore point and the actual timestamp of recovered data;
- start and finish time for infrastructure, data and application recovery;
- technical checks for databases, files, mail, DNS, certificates, integrations and user access;
- business acceptance, deviations from the target and open risks;
- corrective actions, owner and deadline before the next exercise.
Send the workload list, data volume, expected retention, dependencies and business priorities. We will prepare the architecture, test scope and responsibility framework for an individual offer.
Request a Backup and DR planTechnical owner: DataHouse / eTop team. Reviewed: 28 July 2026. Example RPO/RTO bands are educational; exact capacity, retention, recovery objectives, tests, responsibilities, pricing and SLA are confirmed in the offer and agreement.
Decision signals
Covered systems
VPS, dedicated servers, private cloud, VMware, Hyper-V, Proxmox, mail, databases, files, SaaS and business applications
Recovery objectives
workload-specific RPO/RTO, dependency order, service window, acceptance criteria and failback decision
Protection layers
snapshots, repository, off-site copy, immutable or offline copy, second site and separate administrative credentials
Operational evidence
job monitoring, restore-test report, recovered data timestamp, application checks, DNS and network validation
Commercial scope
capacity, retention, ingest and restore performance, test frequency, responsibilities and exact SLA are confirmed in the offer and agreement
Related services
Related guides
Frequently asked questions
What is the difference between backup and disaster recovery?
Backup is the copy of data. Disaster recovery is the process, responsibility and infrastructure needed to restore service after failure.
Why are RPO and RTO important?
They define acceptable data loss and downtime. Without them backup frequency and restore architecture are guesses.
Should backup be tested?
Yes. Restore tests are the only reliable way to confirm that files, databases, mail, applications and dependencies can actually be recovered.
Why should an off-site copy use a separate fault domain?
A copy separated by location, storage and administrative access is less likely to be lost with production during hardware failure, operator error or ransomware.
Does one RPO and RTO fit every business system?
Usually not. Transactional databases, ERP, mail, files and archives should be classified separately because their data-loss tolerance and recovery order differ.
Can DataHouse prepare an individual Backup and DR plan?
Yes. We can map workloads, dependencies and objectives, then scope repository capacity, off-site copies, restore tests, recovery infrastructure and responsibilities in an individual offer.
Which platforms can be included in a Backup and DR plan?
The plan can cover VMware, Hyper-V, Proxmox, physical servers, endpoints, databases, mail, files and business applications. Exact compatibility, agents, licensing and restore methods are confirmed for the actual versions and workload.