What to do if…

My server is down: what should I do?

A server outage is handled in this order: understand the failure, find out whether the data can still be read, choose the last clean restore point, restore, and only then decide whether this server should have had a standby ready. Restoring before you have identified the clean point can mean overwriting the only copy that is still good.

Updated October 20263 min read5 sources cited

Key points

Write down the time and the symptom before touching anything: this will be your starting point for choosing the right copy.
Several machines affected, or files renamed en masse: this is an attack, not a failure. Isolate and follow the ransomware guide.
Do not keep restarting a server whose disks are making noise: every boot can finish off a dying disk.
Restore from the last successful job taken before the incident, after opening a test file from that point.
Time how long it takes to get back up and running: that is your real RTO.

1. Diagnose, without switching everything off at random

Write down the time and the symptom: no network at all, blue screen, clicking disks, an application that will not open, an encryption message.

Power, switch, cable. A server that is “down” is sometimes just a dead link. Are the other machines responding? Is the NAS responding?
A single service. The machine boots, the application does not. That is not the same delay, nor the same restore, as a dead disk.
Several machines at once, or files renamed en masse. Treat this as an attack, not a hardware failure: cut Internet access for the affected network, unplug the affected machines without shutting them down and go to Ransomware has just struck. Do not restore onto a network that is still on fire.

If the physical server smells of burning, or the disks cannot be heard, and you have no copy, stop switching it back on again and again: every boot can make a dying disk worse. The backup copy becomes the priority.

2. Determine whether the data is intact

Three situations:

The system is dead, but the data disks still respond from another connection or a live CD. You can make an emergency copy to a healthy disk, then restore properly. This emergency copy is no reason to skip the off-site backup: it may be incomplete.
The files are there and open. A software or partial hardware failure. A repair may be enough. Back up the current state before attempting destructive repairs, if that state is still clean.
The files are unreadable, missing or encrypted. Production is no longer a source. Only an earlier backup is.

3. Identify the last restore point

In the backup console, take the last successful job and check that it predates the incident. If the failure is corruption discovered today but which started a week ago, yesterday’s job is a poor candidate. Open a test file from that point before launching the full restore.

Find out where the encryption key is. Without it, the point exists but remains unreadable.

4. Restore

Files only if the system is healthy and only a folder is missing.
Whole server if the system is dead: image to equivalent hardware or to a virtual machine. This is faster than reinstalling by hand, provided the image has been tested at least once in the year.
Do not restore over a disk that may hold the only recent data not yet backed up, until that doubt has been cleared.

If several servers need restarting, follow the order of dependencies: directory and network first, then databases, then applications, then workstations. The French cybersecurity agency (ANSSI) recommends defining this restore order in advance, taking into account dependencies and how critical each application is.

Time it. That figure is your real RTO.

5. Consider a DRP if the server is critical

If the outage has already cost too much, or there is no replacement hardware, the DRP is there to restart now on a standby instance, from the chosen point, while the hardware is repaired. If this server goes down often, or if management will no longer accept this delay, it must be brought into the DRP or the BCP after the incident, in writing, not just in the evening’s conversation.

Degraded mode (paper, another tool) is triggered alongside steps 3 and 4, not after them.

After the incident: the post-mortem

Within the week, write down what took longer than expected, what was missing (password, key, contact, hardware) and what changes in the plan. If the cause is an attack, keep the traces and logs: the complaint to the Mauritius Police Force (Cybercrime Unit) must be filed before the machines are reinstalled, and a personal data breach must be notified to the Data Protection Commissioner, where feasible within 72 hours (Data Protection Act 2017, section 25).

At WeDoBack

WeDoBack can restore the complete server, with its system, software and settings, or just the files. The copies are stored away from the failed server, encrypted, with the key held by the customer. With the DRP, servers restart on standby instances from the version you choose, without waiting to buy a machine; activation is billed per day. Support can be reached on +33 9 72 50 78 28, from 9:00 to 13:00 and from 14:00 to 17:30 (Paris time), i.e. from 11:00 to 15:00 and from 16:00 to 19:30 Mauritius time during European summer time, and one hour later in winter. Outside these hours, monitoring may have raised an alert, but assisted restoration waits until opening time, unless otherwise arranged in the contract.

Call +33 9 72 50 78 28 Discover the DRP

Frequently asked questions

Should I shut the server down?

For a confirmed hardware failure (burning smell, clicking disks), yes: stop restarting it. If you suspect an attack, isolate it from the network rather than shutting it down: memory may hold evidence useful to the investigation, as CERT-MU points out in its incident handling guideline.

How long does it take to restore a server?

It depends on the volume, the bandwidth, the method (files or full image) and whether replacement hardware is available. Without a tested system image, allow anywhere from half a day to two days for a physical server. A DRP lets you restart on a standby instance without waiting for hardware.

Should I notify anyone other than my IT provider?

If the outage is caused by an attack and personal data is affected, the breach must be notified to the Data Protection Commissioner without undue delay and, where feasible, within 72 hours (Data Protection Act 2017, section 25), via the eDPO portal. Also report the incident to CERT-MU through MAUCORS+, inform your insurer if your policy covers cyber risk, and file a complaint with the Mauritius Police Force (Cybercrime Unit) before reinstalling the machines.

Sources

Documents consulted in October 2026.

Guideline on Incident Handling and Reporting — CERT-MU
Information system backup – The fundamentals (ANSSI-BP-100, v1.1, 27 November 2025, in French) — ANSSI (French cybersecurity agency)
eDPO: online notification of personal data breaches — Data Protection Office (Mauritius)
SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
DRP offer (Disaster Recovery Plan) — WeDoBack

Need help now?

Do not restore anything until you have identified a clean copy. We can guide you.

Call +33 9 72 50 78 28 or write to us

Dealing with an incident right now?

Our teams help you identify the right copy and restore it, Monday to Friday, 9 am to 1 pm and 2 pm to 5:30 pm (Paris time).

Call +33 9 72 50 78 28 Write to the team