--- title: "Backup and disaster recovery" description: "Backup, immutable storage, disaster recovery and business continuity planning, with restores rehearsed on a schedule." url: https://www.expandware.com/services/managed-it/backup-and-disaster-recovery/ section: "Services" topics: ["Managed IT", "ISO 22301", "NIST SP 800-34", "Veeam", "Commvault"] publisher: "Expandware Private Limited" --- # Backup and disaster recovery Backup, immutable storage, disaster recovery and business continuity planning, with restores rehearsed on a schedule. Recovery you have tested, not recovery you hope for. Backups are judged by restores. We design protection from the recovery objectives the business can tolerate, how much data it can lose and how long it can be down, then implement backups that ransomware cannot reach, replicate what has to fail over, and rehearse recovery on a schedule so the first real restore is not the first restore. Where it usually starts: - Nobody has restored anything from backup in the last year. - Backups sit on the same network, behind the same credentials, as the systems they protect. - Recovery objectives exist in a policy but not in the design. - Microsoft 365 or Google Workspace data is assumed to be backed up by the provider. What is included: - Recovery objectives: Recovery point and recovery time objectives agreed with the business for each system. - Backup design: Servers, virtual machines, databases, cloud and SaaS data, protected to those objectives. - Immutable copies: Offline or immutable storage that ransomware and stolen credentials cannot delete. - Disaster recovery: Replication and failover to a second site or a cloud region. - Restore testing: Scheduled restores and full recovery rehearsals, with the results recorded. - Continuity planning: Runbooks, contact trees and decision rights for a real disaster. Where it sits: Backup and recovery form the assurance layer of the managed IT architecture: protected copies of servers, cloud and SaaS data, with off-site and immutable copies that survive the loss of the site or the credentials that run it. Decisions to settle early: - How much loss each system can bear. Tighter objectives cost more to meet. Each system's owner decides what downtime and data loss really cost the business. - Second site or cloud recovery. A standby site recovers fastest but costs most; a cloud region costs little until it is used. The objectives decide. - Who holds the keys to the backups. Backups protected by the same accounts as production fall together. Separate credentials and immutability decide whether the copy survives. How the work runs: Define, Recovery objectives for each system. Protect, Backups, immutability and replication. Rehearse, Restores and failovers on a schedule. Report, Evidence of every test. How it is bought: - A fixed-fee assessment: We review what is backed up, where copies live, who can delete them and when a restore was last tested, then restore a sample system. You receive the findings and a fixed price for remediation. - A fixed-price build: Agreed recovery objectives, the redesigned backup architecture, immutable and off-site copies, replication for critical systems and runbooks, at a fixed price. - Running it afterwards: Protection then runs monthly: monitoring every job, scheduled restore tests and recovery rehearsals, with the evidence recorded for audit. Worked example, backups that had never been restored. Say a logistics company backs up its servers every night to an appliance on the same network, with the same administrator accounts. Nobody has tested a full restore, and ransomware has just hit a competitor. - Define: We agree with each system's owner the data loss and downtime it can tolerate, starting with dispatch and billing. - Protect: Backups are rebuilt to those objectives, with an immutable copy that the production administrator accounts cannot delete. - Replicate: The systems the business cannot run without are replicated to a cloud region, so they can be started there if the site is lost. - Rehearse: Restores are tested on a schedule, and a full recovery of dispatch is rehearsed with the operations team timing it. At the end, the company knows how long recovery takes because it has done it, and an attack on the production network cannot reach the copy it would need. (An illustration, not a client account.) What you have at the end: - Recovery objectives for each system: The data loss and downtime each system can tolerate, agreed with the person who owns it. - Backup and disaster recovery architecture: The design that meets those objectives: backup targets, immutable copies, replication and failover. - Disaster recovery runbooks: Step by step recovery for each system and scenario, in the order the business needs its services back. - Restore test reports: The result of every scheduled restore and rehearsal, with the time it took and anything that failed. - Business continuity plan: Who decides, who is told, and what the business does while its systems are being recovered. Standards and platforms worked with: ISO 22301, NIST SP 800-34, Veeam, Commvault, Rubrik, Azure Backup, AWS Backup, 3-2-1 backup rule. Where it goes wrong, and what we design out: - Backups an attacker can delete. Copies reachable with production credentials disappear in a ransomware attack. At least one copy is immutable or offline. - Never restoring anything. An untested backup is a hope. Restores are rehearsed on a schedule and timed. - Assuming SaaS is protected. Most SaaS providers protect their service, not your data from deletion or attack. SaaS data is backed up like any other system. What it changes: - Ransomware is survivable. Immutable copies mean an attacker who encrypts production cannot also destroy the way back. - Recovery times that are known. Rehearsals measure how long recovery actually takes, so the objective is a fact rather than a hope. - Evidence for auditors and insurers. Test results answer the questions cyber insurers and auditors now ask. How you will know it is working: - You know how long each critical system takes to recover, because it has been done. - At least one copy sits beyond the reach of production credentials. - Restore tests are recorded and reviewed. - Recovery objectives are reflected in the design, not only in a policy. Who you work with: - Recovery architect. Designs protection to the recovery objectives and owns the recovery runbooks. - Backup engineers. Run and monitor the jobs, and carry out the scheduled restore tests. - Continuity adviser. Works with your leadership on decision rights and the continuity plan. What we need from you: - A list of systems and their business owners. - Access to the current backup tools and storage. - Decisions on recovery objectives from people able to make them. - Time for a recovery rehearsal with the teams involved. Common questions: Q: Does Microsoft back up our Microsoft 365 data? A: Microsoft keeps the service available and offers limited retention, but protection against deletion, corruption or ransomware inside your tenant is your responsibility. A separate backup closes that gap. Q: How often should we test restores? A: Individual restores monthly, and a full recovery rehearsal of critical systems at least once a year, more often for systems that change quickly. We schedule both and record the results. Q: What makes a backup immutable? A: Storage that cannot be altered or deleted for a defined retention period, even by an administrator, such as object lock in cloud storage or a hardened backup repository. It is the control that matters most against ransomware. Q: Can we recover into the cloud? A: Yes. A cloud region is often the most economical disaster recovery site, provided the network, identity and licensing are prepared in advance. Q: What are recovery point and recovery time objectives? A: The recovery point objective is how much data a system can afford to lose, measured back from the moment of failure. The recovery time objective is how long it can be unavailable. Together they decide how often a system is backed up, whether it needs replication, and what its protection costs. Q: Does disaster recovery have to mean a second data center? A: No. For many organizations a cloud region is the recovery site, with systems replicated there and started only when needed. The design follows the recovery objectives, and the cost of a standby site is weighed against the cost of the downtime it avoids. Q: What does the 3-2-1 backup rule mean? A: Keep at least three copies of your data, on two different types of storage, with one copy off site. We add an immutable or offline copy and a tested restore, because a backup that an attacker can delete, or that has never been restored, does not really count. Q: Who decides to invoke disaster recovery? A: Named people in the business continuity plan, agreed in advance, with deputies. Failing over has costs and risks of its own, so the decision belongs to someone with authority, and the plan sets out the information they need to make it quickly. Often paired with: Incident response, Monitoring and network operations, Hybrid and private cloud. --- Canonical page: https://www.expandware.com/services/managed-it/backup-and-disaster-recovery/ Site index for machines: https://www.expandware.com/llms.txt Full site text: https://www.expandware.com/llms-full.txt Expandware Private Limited. Inquiries: solutions@expandware.com, +92 (333) 32 11011.