The ways backups fail

• The backup job stopped months ago and nobody noticed
• The backup is stored on the same server that just failed
• The backup is incomplete (database yes, uploaded files no)
• The files are corrupted or empty
• Nobody knows the encryption password
• Restoring takes three days, and the business cannot wait that long
• The backup contains yesterday's ransomware infection
• The only person who knew how to restore left the company

The 3-2-1 rule

A simple standard that covers most risks:

• 3 copies of your data (the live one plus two backups)
• 2 different types of storage (for example, a server's disk and cloud storage)
• 1 copy off-site, in another location and under a different account

Modern advice adds: keep at least one copy that cannot be modified or deleted from your main systems (immutable or offline), so ransomware or a compromised account cannot wipe it.

Step 1: Decide what needs backing up

Think in terms of data you cannot recreate:

• Databases (the most important item for most businesses)
• Uploaded files and documents
• Configuration: server settings, environment variables, secrets (stored securely)
• Source code (it should already be in version control, which counts as a copy)
• Email, if you host it yourself
• SaaS data: many people assume their cloud tools back everything up for them. Often they offer limited recovery windows, and not for your mistakes. Export what matters (see leaving a SaaS without losing your data)

Also decide what you do not need, such as caches, temporary files and things that can be rebuilt from code.

Step 2: Set two numbers

Two questions turn "we have backups" into a real plan:

• How much data can we afford to lose? If the answer is one hour, daily backups are not enough. This is the recovery point objective.
• How long can we be down? If the answer is four hours, a restore that takes two days is a failure. This is the recovery time objective.

For a small business the answers might be "one day" and "one day", and that is fine. What matters is that they are known and the setup matches.

Step 3: Automate and monitor

• Backups run automatically, never from memory
• Each run reports success or failure, and failures reach a real person
• A "no news" setup is dangerous: configure an alert when a backup has not run, not only when it errors
• Check backup size over time. A sudden drop to nearly zero is a red flag

Step 4: Protect the backups

• Encrypt them, and store the key separately from the backups (in your password manager, with at least two people able to access it)
• Use a separate account or credentials for backup storage, so a compromise of the main system cannot delete them
• Limit who can delete backups, and enable retention rules
• Keep several generations: daily for a few weeks, weekly for a few months, monthly for longer. A problem is often noticed days after it started

Step 5: Test the restore (the part everyone skips)

At least twice a year, and after any major change:

1. Choose a backup at random, not the latest one every time.
2. Restore it to a clean, separate environment, never over production.
3. Follow your written procedure, ideally performed by someone who did not write it.
4. Verify the result: can you log in, are recent records present, are files and images intact, do key features work?
5. Time it. Compare against your recovery time target.
6. Write down what went wrong and fix the procedure.

The first test nearly always reveals a gap. That is the point. It is much cheaper to find it now. The same idea sits in an exit plan: document backups, then prove the restore.

Step 6: Write a one-page restore procedure

It should be usable by someone stressed and in a hurry:

• Where the backups are, and how to get access
• Where the encryption keys are
• The exact steps to rebuild a server and restore data
• Who to call, and who decides
• Expected duration
• How to verify success
• Date of the last successful test

Keep a copy somewhere that does not depend on the system that might be down. A procedure stored only on the failed server is not much use.

Special cases

Databases: copying database files while the database is running can produce an unusable backup. Use the database's own export or backup tool, or a method that guarantees a consistent snapshot.

Virtual machine snapshots: convenient, but usually stored with the same provider and sometimes in the same place as the machine. Treat them as one layer, not the whole plan.

Hosting provider backups: useful, but check how long they keep them, where they are stored, whether you can download them, and what happens if your account is suspended. When you switch hosts, set backups and a restore test on the new side before you cancel the old one.

Ransomware: make sure at least one backup copy is out of reach of your normal credentials, and test that you can restore from it.

A small-company setup that works

• Daily automated database export and file backup
• Copy sent to a second provider, under a separate account
• Weekly copy kept for two months, monthly copy for a year
• Alerts if a backup is missing
• A test restore every six months, with the date recorded
• A one-page procedure, known to at least two people

None of this is expensive. It is mostly a matter of doing it once, writing it down and checking it regularly.

Quick audit

• I know what is backed up and what is not
• At least one copy is outside my main provider
• Someone gets an alert if a backup fails or does not run
• I can find the encryption key without the person who set it up
• I have restored a backup successfully in the last six months
• I know how long a full restore takes

Every "no" is the next task on your list.

Comment les sauvegardes échouent

• Le job s'est arrêté il y a des mois et personne n'a vu
• La sauvegarde est sur le même serveur qui vient de tomber
• La sauvegarde est incomplète (base oui, fichiers uploadés non)
• Les fichiers sont corrompus ou vides
• Personne ne connaît le mot de passe de chiffrement
• La restauration prend trois jours, et l'activité ne peut pas attendre
• La sauvegarde contient l'infection ransomware d'hier
• La seule personne qui savait restaurer a quitté l'entreprise

La règle 3-2-1

Un standard simple qui couvre la plupart des risques:

• 3 copies de vos données (la live plus deux sauvegardes)
• 2 types de stockage différents (par exemple disque serveur et stockage cloud)
• 1 copie hors site, dans un autre lieu et sous un autre compte

L'avis moderne ajoute: garder au moins une copie qu'on ne peut ni modifier ni supprimer depuis vos systèmes principaux (immuable ou hors ligne), pour qu'un ransomware ou un compte compromis ne puisse pas l'effacer.

Étape 1: Décider quoi sauvegarder

Pensez en termes de données irremplaçables:

• Bases de données (souvent le plus important)
• Fichiers uploadés et documents
• Configuration: réglages serveur, variables d'environnement, secrets (stockés correctement)
• Code source (déjà en contrôle de version, ce qui compte comme une copie)
• Email, si vous l'hébergez vous-même
• Données SaaS: beaucoup croient que l'outil cloud sauvegarde tout. Souvent la fenêtre de récupération est limitée, et pas pour vos erreurs. Exportez ce qui compte (voir sortir d'un SaaS sans perdre ses données)

Décidez aussi de ce dont vous n'avez pas besoin: caches, fichiers temporaires, tout ce qui se reconstruit depuis le code.

Étape 2: Fixer deux chiffres

Deux questions transforment « on a des backups » en vrai plan:

• Combien de données pouvons-nous perdre ? Si la réponse est une heure, une sauvegarde quotidienne ne suffit pas. C'est l'objectif de point de reprise (RPO).
• Combien de temps pouvons-nous être hors service ? Si la réponse est quatre heures, une restauration de deux jours est un échec. C'est l'objectif de temps de reprise (RTO).

Pour une PME, « un jour » et « un jour » peut suffire. L'important est que ce soit dit, et que le dispositif suive.

Étape 3: Automatiser et surveiller

• Les sauvegardes tournent automatiquement, jamais de mémoire
• Chaque run signale succès ou échec, et les échecs arrivent à une vraie personne
• Un dispositif « pas de nouvelles = tout va bien » est dangereux: alertez aussi quand une sauvegarde n'a pas tourné, pas seulement en cas d'erreur
• Suivez la taille des sauvegardes. Une chute vers zéro est un signal d'alarme

Étape 4: Protéger les sauvegardes

• Chiffrez-les, et stockez la clé à part (coffre / gestionnaire, avec au moins deux personnes qui y ont accès)
• Compte ou identifiants séparés pour le stockage de backup, pour qu'une compromission du système principal ne puisse pas tout effacer
• Limiter qui peut supprimer, et activer des règles de rétention
• Garder plusieurs générations: quotidiennes quelques semaines, hebdomadaires quelques mois, mensuelles plus longtemps. Un problème se remarque souvent des jours après

Étape 5: Tester la restauration (ce que tout le monde saute)

Au moins deux fois par an, et après tout changement majeur:

1. Choisir une sauvegarde au hasard, pas toujours la dernière.
2. Restaurer dans un environnement propre et séparé, jamais sur la production.
3. Suivre la procédure écrite, idéalement par quelqu'un qui ne l'a pas rédigée.
4. Vérifier le résultat: connexion possible, enregistrements récents présents, fichiers et images intacts, fonctions clés OK.
5. Chronométrer. Comparer au RTO.
6. Noter ce qui a cloché et corriger la procédure.

Le premier test révèle presque toujours un trou. C'est le but. C'est bien moins cher de le trouver maintenant. La même idée figure dans un plan de sortie: documenter les backups, puis prouver la restauration.

Étape 6: Une procédure de restauration d'une page

Elle doit servir à quelqu'un stressé et pressé:

• Où sont les sauvegardes, et comment y accéder
• Où sont les clés de chiffrement
• Les étapes exactes pour reconstruire un serveur et restaurer les données
• Qui appeler, et qui décide
• Durée attendue
• Comment vérifier le succès
• Date du dernier test réussi

Gardez une copie qui ne dépend pas du système qui peut être down. Une procédure stockée uniquement sur le serveur en panne ne sert pas à grand-chose.

Cas particuliers

Bases de données: copier les fichiers pendant que la base tourne peut donner une sauvegarde inutilisable. Utilisez l'export ou l'outil de backup de la base, ou une méthode de snapshot cohérent.

Snapshots de machine virtuelle: pratiques, mais souvent chez le même fournisseur et parfois au même endroit que la machine. Une couche, pas tout le plan.

Sauvegardes de l'hébergeur: utiles, mais vérifier durée de conservation, lieu de stockage, possibilité de télécharger, et ce qui se passe si le compte est suspendu. Quand vous changez d'hébergeur, activez backups et test de restore côté nouveau avant de résilier l'ancien.

Ransomware: au moins une copie hors de portée de vos identifiants habituels, et testez que vous pouvez restaurer depuis elle.

Un dispositif PME qui marche

• Export base et fichiers automatisés chaque jour
• Copie vers un second prestataire, sous un compte séparé
• Copie hebdo gardée deux mois, mensuelle un an
• Alerte si une sauvegarde manque
• Test de restauration tous les six mois, date notée
• Procédure d'une page, connue d'au moins deux personnes

Rien de tout cela n'est cher. C'est surtout le faire une fois, l'écrire, et le vérifier régulièrement.

Audit rapide

• Je sais ce qui est sauvegardé et ce qui ne l'est pas
• Au moins une copie est hors de mon prestataire principal
• Quelqu'un est alerté si une sauvegarde échoue ou ne tourne pas
• Je peux trouver la clé de chiffrement sans la personne qui l'a configurée
• J'ai restauré une sauvegarde avec succès au cours des six derniers mois
• Je sais combien de temps dure une restauration complète

Chaque « non » est la prochaine tâche de votre liste.