In technical meetings the objection almost always arrives in the same form: «we already do backups». The sentence closes the subject and moves attention elsewhere. Then three questions arrive: how long since anyone checked the outcome of the overnight jobs, where the most recent copy sits, when the last documented restore took place. The subject reopens. Between backup and disaster recovery runs the same distance that separates holding the data from having a working company again.
On the server room floor the difference is understood. In the boardroom it arrives blurred. Backup and disaster recovery appear on the accounts under one heading and get read as an expense already covered.
Backup and disaster recovery are two separate projects
Copying the data and putting the company back to work require different arrangements. Backup produces copies, disaster recovery guarantees the restart: two activities that share technology, answer different questions and are therefore sized differently.
An overnight copy onto an on site appliance allows recovery of a file deleted by mistake or a document overwritten. It does not solve a server failure. The component has to be bought or repaired before anything can be restored, and procurement time becomes part of the outage. The formula we hear most often is «a sort of disaster recovery». It describes an archive on a network device plus a cloud replica that would allow a warm restart. The conditional in that sentence is the interesting part: it indicates that nobody has ever tried.
Genuine disaster recovery implies duplicated resources. It requires an environment replicating production alone, with mirrored application and database servers ready to run. It has to account for the time needed to move network references towards the secondary site. On one project for a financial sector application the requirement was to be operating at the alternate site within half an hour, domain name changes included. Minimum separation between the two locations: one hundred and fifty kilometres.
Between the two extremes sits a middle route that in many organisations is the proportionate answer. Automatic conversion of the latest copy image into a virtual machine ready to boot, working incrementally from the second run onwards. The resulting machine starts on the virtualisation environment already present in the company or, if that is unavailable too, on the cloud infrastructure of the copy provider. No dedicated second site is required and no permanent connectivity, and the answer to «how long are we down» moves from days to hours.
RTO and RPO are set per service
Both acronyms have circulated for years and get repeated in presentations without ever being translated into numbers. The operational wording is simple: how long the activity can stay stopped, and what data loss, expressed in hours of work, is acceptable.
Translating backup and disaster recovery into numbers calls for an impact analysis. Identify the services that keep the company running, establish for each the maximum period within which it must return, and build the architecture on that period. The second step decides everything, because the values are not identical across the systems of a single organisation.
A director of a multi site healthcare group put it clearly. Administration can stay down for a few hours, clinical operations for very few minutes, because patients cannot wait for a treatment. Within the same company, then, two different recovery architectures and two different levels of investment coexist. Applying one value to everything over specifies what does not need it and leaves exposed what does.
Where the analysis is missing, the answer is nearly always the same. «There is no analysis here, nothing at all», followed by: «we have never faced it and never thought it could happen to us». Those two sentences precede, in our experience, the most urgent projects.
A week of downtime caused by one failed disk
A software house of under twenty staff develops and hosts business applications for customers in healthcare and the cooperative sector, on two physical servers at an Italian provider. Copies of the database ran regularly, in full and in part. Each of them was written to the very machine delivering the service.
The risk was known internally. «We would need a copy on an external machine, at the moment if something stops we are stuck»: the weakness had been acknowledged, not funded.
Then a disk in the redundant group failed. The whole load moved onto the remaining unit, the processor hit full scale and the system began dropping repeatedly. The only available move was to buy another machine and shift everything across, an operation beyond the skills of the person in house.
Service to customers stayed interrupted for around a week: the time to buy hardware, migrate systems and reload the copy. During those days the end customers, healthcare practices and cooperatives, worked without their business software.
What gets told less often came afterwards. When the provider replaced the original machine, the company found itself with a spare server that should have become the continuity node or the store for external copies. It sat empty and unused for a year. The stated objective after the experience was clear: «if instead of a week the outage were an hour that would be a fine thing». Nobody turned it into a project with owners and deadlines.
Insight. The event that triggers the damage is almost always mundane and predictable. Outage length depends largely on how many decisions remain to be taken at the moment the failure appears. Purchases to authorise, skills to find, priorities to set without a written procedure.
Why a cloud mailbox still needs a separate copy
Outage thresholds apply to email as well, and in the hierarchy of critical services email sits almost always at the top alongside business software. «It is in the cloud, so it is safe» survives any technical explanation. The objection has its own logic: a provider guarantees that the service works. It does not guarantee recovery of the content. Three typical cases: a message deleted beyond the native retention window, a compromised account that empties folders, a person who leaves and clears their own archives. In none of them does an obligation to hand anything back exist.
Native windows typically sit between thirty and ninety days and cover accidental deletion noticed straight away. They do not cover the need to recover a document twelve months later, nor the retention obligations many companies carry by contract or by law. Under the managed service we deliver, the tenant copy is daily, with a minimum retention of six months on our own systems in Italian data centres. Outcomes are verified periodically and restore is granular, down to the single message or file.
Two tools worth keeping apart are frequently confused. A copy exists to put a system back into operation. Archiving answers a request for evidence that arrives months later. It preserves an immutable, indexed and searchable version, unalterable even by whoever administers the system, and it carries evidential value. Both are needed, for different purposes. The continuous oversight we described when discussing compliant digital preservation applies to copies as well: without someone checking the outcome, an active service is not a supervised service.
Backup and disaster recovery: how to prove that a restore works
The practical difference between backup and disaster recovery is measured here. A copy job that ends successfully says the data has been written. It does not say the data is readable, nor that the machine will boot. Both checks are performed differently and they complement each other.
Validation by comparison comes first: the system rereads the restore point in full and verifies it against what was written. That anticipates the operation which would be carried out during a real restore. It takes time and bandwidth, so in most cases it is scheduled separately from the copy job. The task can be handed to another system with access to the archive. In a small operation with one server and a dozen workstations, the weekend is the natural window.
The second is functional verification: the system boots the protected machine in an isolated virtual environment and checks that it reaches its operating screen. Image analysis is automated and the outcome enters reporting as evidence. That answers the situation which most alarms anyone who has already lived through an incident, namely an archive present but unbootable.
A third scenario rarely enters the assessment. Malware can sit dormant in an estate for weeks before activating, contaminating copies in the meantime. Restoring from an already compromised archive repeats the problem instead of solving it. The countermeasure is periodic scanning of archives, run without involving workstations, to identify in advance the most recent clean restore point.
Seven checks to ask of whoever runs backup and disaster recovery
- An off site copy exists, on media that shares neither power nor network with the protected system.
- An immutable copy exists, with a configured lock window, that an attack holding administrative credentials could neither encrypt nor delete.
- Somebody reviews job outcomes every week and reports anomalies by the next working day.
- A documented test restore exists, with date, scope and actual duration, carried out within the last thirty days.
- Boot media for bare metal recovery has been tested on the real hardware, to rule out missing controller and network drivers.
- An operating document lists step by step who does what in the first two hours, with current names and contact details.
- Responsibilities for backup and disaster recovery are assigned in writing, with a named deputy for every role.
Three levels of protection and what each one promises
| Level | What it covers | Order of magnitude for restore |
|---|---|---|
| Daily on site copy | Deleted or overwritten file, contained application error | Minutes for a single file, days if the server must be replaced |
| Off site copy and immutable archive | Ransomware holding administrative credentials, deliberate deletion, site incident | Hours, depending on volume and available connectivity |
| Replication to a second site with automated start | Blocking hardware failure, prolonged unavailability of the primary site | Minutes, with a written procedure tested in advance |
Questions that surface when the continuity plan is reopened
What changes between an immutable archive and an offline copy on removable media?
Disconnected removable media stays untouchable as long as nobody connects it, but it introduces a manual step and a physical custody risk. An immutable archive reaches the same result without human intervention. Once the window is set, the data cannot be deleted or altered until expiry, not even with administrative credentials belonging to the customer or the supplier. Minimum windows start at fourteen days and extend according to retention needs.
Is consolidating onto a single copy tool worthwhile?
Fragmentation between different tools for infrastructure and for cloud email produces two measurable consequences. Less defined responsibility when something fails, and reporting that has to be reassembled by hand before an audit. Consolidation is almost always the right direction, but the choice belongs to the requirements rather than to habit. One certified IT manager framed it exactly right: the question is not which product he prefers, it is which one satisfies the standard he has to meet.
What evidence is needed if a customer or an auditor asks about continuity?
Documents rather than statements. A continuity plan reviewed annually, a recovery plan with the outcomes of periodic tests, an up to date impact analysis. Then attestation of copy policies and verification activity, a vulnerability register, a record of interventions on systems. Companies inside regulated supply chains are asked for that package by their own customers, and it is built over time. Our piece on protecting corporate documents sets out the operating model for producing evidence continuously.
How often should a test restore be run?
Under the advanced plans we manage, monthly tests are run and documented on representative samples, with the outcome reported in periodic reviews. For virtualised environments a boot test is added, verifying that the machine actually starts rather than that the archive merely reads. Frequency should be calibrated on the value of the system: whatever supports daily operations needs closer checking than historic archives.
Does any regulation impose a second site?
That depends on the sector and on the company’s role in the supply chain, and verification belongs with a regulatory adviser. On principle, Article 32 of the General Data Protection Regulation applies. It requires the ability to restore availability and access to data in a timely manner after a physical or technical incident. It also requires a process for regularly testing the effectiveness of the measures adopted. Periodic testing, therefore, is not an optional good practice.
Let’s talk
The quickest way to find out where a company stands on backup and disaster recovery is to set a date and try. Not a paper exercise: a real restore on a system chosen together, stopwatch running and the result written down. It is the first thing we put in the diary during the free consultation, before any proposal. That number is the only one that counts on the day of the outage. In most cases it differs from the one the board has in mind.
Aesir Srl works as an MSP and MSSP under the same contractual perimeter, with its own Tier IV data centres in the European Union and replication. Certifications are ISO 9001, 27001, 27017 and 27018, with voluntary alignment to NIS2, and projects run throughout Italy. If you would like to explore the subject or assess the situation in your own company, you can fill in the form at the bottom of this page or write to support@aesir-tech.it: we will arrange a free consultation and start from your numbers.