A ransomware message on a Monday morning, a failed server during month-end, or an accidental deletion from a shared Microsoft 365 folder can stop work far more quickly than most businesses expect. Disaster recovery is the plan that determines whether your team can continue serving customers within hours, or spends days trying to piece systems and data back together.
For Irish businesses, the issue is not simply whether files are backed up. It is whether the right people can access the right systems, from the right location, within an agreed timeframe. That requires clear priorities, dependable technology and regular testing – not a backup device quietly running in a cupboard.
What disaster recovery means in practice
Disaster recovery is the process of restoring IT services, data and access after a serious disruption. The disruption may be a cyber attack, power failure, hardware fault, flood, fire, internet outage or a mistake made by a member of staff. It sits within wider business continuity planning, but focuses specifically on the technology your organisation needs to operate.
A useful plan looks beyond the server room. It considers cloud applications, laptops, network equipment, telephone systems, email, line-of-business software and the credentials employees need to work remotely. If one of these components is missing, restoring data alone may not get the business moving again.
The right approach depends on your operation. A small professional services firm may need email, client files and accounting software restored quickly. A multi-site organisation may also need site connectivity, wireless networks, central servers, devices and critical applications recovered in a planned order. There is no value in restoring a system first if the people who use it cannot log in or reach it.
Start with business impact, not backup products
Technology choices should follow operational requirements. Before selecting storage, cloud replication or backup software, identify what a disruption would cost and which services cannot be unavailable for long.
Ask four practical questions:
- Which systems stop revenue, customer service or compliance activity when unavailable?
- How long can each system be down before the impact becomes unacceptable?
- How much recent data can the business afford to lose?
- Who has authority to make decisions and communicate with staff, customers and suppliers during an incident?
These answers establish two essential recovery measures. The recovery time objective, or RTO, is the maximum acceptable time to restore a service. The recovery point objective, or RPO, is the maximum acceptable amount of data loss measured in time. For example, if a finance system is backed up every four hours, up to four hours of changes could be lost after a failure.
An organisation may set a short RTO for email and a longer one for archived records. That is sensible. Trying to provide instant recovery for every application can be unnecessarily expensive, while accepting lengthy downtime for a customer-facing system can create a much larger commercial problem. The aim is proportionate protection, based on how your business actually works.
Backup is necessary, but it is not the whole plan
Backup and disaster recovery are closely connected, yet they are not interchangeable. A backup is a recoverable copy of data. Disaster recovery is the process, people and infrastructure used to restore normal operations.
A backup can fail to provide the recovery you expect for several reasons. It may not include a critical application configuration, it may be too old, it may be inaccessible during an attack, or restoring it may take longer than the business can tolerate. Backups can also be affected by ransomware if they remain permanently connected to the same environment as the systems they protect.
A sensible backup design normally includes separate copies in different locations, with at least one copy protected from alteration or deletion. The exact architecture varies by risk and budget. Some businesses need encrypted cloud backup with retained versions; others may require local recovery capacity for speed alongside an off-site copy for resilience. Where servers and essential applications are involved, replication to a secondary environment may be appropriate.
Microsoft 365 deserves particular attention. Microsoft provides a highly available platform, but availability is not the same as a complete backup strategy for your own data. Retention settings, deleted items, Teams conversations, SharePoint libraries and OneDrive files need to be considered against your recovery requirements. A clear policy prevents unpleasant surprises when a user asks for a file from several months ago.
Build a disaster recovery plan people can use
A plan written once and stored in an inaccessible folder is unlikely to help during an incident. It should be concise enough to use under pressure, while still documenting the technical detail required to recover systems safely.
Start with a current inventory of assets and dependencies. Record where data is held, which applications rely on particular servers or cloud services, who administers them, and how licences, passwords and recovery keys can be accessed securely. Include network diagrams and supplier contact details where relevant. If an office loses connectivity, staff should not have to guess which firewall, broadband circuit or telephone provider is in place.
Then set the recovery sequence. In many cases, identity and access services come first, followed by network connectivity, core infrastructure and business applications. End-user devices may be restored or replaced after the central services are available. The sequence should reflect your priorities rather than the order in which equipment happens to be located.
Your plan should also set out communications. Staff need a clear route for reporting issues and receiving updates. Customers may need reassurance if a service is affected. Senior management needs timely information about impact, decisions and expected recovery times. Assign named roles, but provide a deputy for each one. A plan that depends on one person being available is a weak point.
Test recovery before an incident tests it for you
Testing is where many otherwise good plans fall short. A successful backup report confirms that a job ran. It does not confirm that a full server, application or set of files can be restored within the agreed RTO.
Begin with routine restore tests for individual files and mailboxes. Progress to application recovery, virtual server restoration and scenario-based exercises that involve the people responsible for decision-making. For a more mature programme, test a realistic loss of a key system or office location and record how long each stage takes.
Testing often reveals practical issues: an outdated administrator account, missing encryption keys, insufficient internet capacity for cloud recovery, undocumented application dependencies or a recovery process that requires a supplier who is unavailable outside normal hours. Finding these gaps during a planned exercise is far less costly than finding them during a live outage.
Review the plan after every test, material system change, office move or security incident. New cloud services, changed staff responsibilities and ageing hardware can all alter the recovery position. Disaster recovery is an operational discipline, not a one-off project.
Protect recovery from cyber attack
Cyber recovery requires extra care because an attacker may have been present in the environment long before encryption or data theft becomes visible. Restoring the latest backup without investigation can reintroduce compromised accounts or malicious files.
Your response should combine recovery with security controls. Isolate affected systems, preserve evidence where required, reset compromised credentials, review privileged access and confirm that restored systems are patched before they return to service. Multi-factor authentication, endpoint protection, network segmentation and monitored backups all reduce the chance that one incident becomes a full business shutdown.
It is also worth agreeing how cyber incidents will be escalated. Your IT support provider, cyber insurer, legal advisers and leadership team may each have responsibilities. Knowing who to call, and in what order, removes delay when decisions matter most.
Turn a plan into dependable support
The best disaster recovery arrangements are maintained continuously. They account for new users, replaced devices, updated applications and changing business priorities. They also give decision-makers plain answers: what is protected, how quickly it can be recovered, and what risk remains.
LANCAST helps businesses bring backup, infrastructure, cybersecurity and managed support into one practical recovery strategy. That can reduce the hand-offs between separate suppliers when an incident affects more than one part of the IT environment.
A worthwhile next step is to choose one critical system and ask a simple question: if it failed at 9am tomorrow, who would restore it, from where, and how long would it take? The answer will show you where to begin.