Hébergement
Sauvegarde externalisée
Une sauvegarde n'existe que si elle se restaure. Nous externalisons vos données, nous les rendons immuables, et nous éprouvons la restauration.
- Chiffrement de bout en bout
- Copies immuables
- Restaurations éprouvées
Le principe
Ce qui compte n'est pas la copie, c'est le retour
Sauvegarder est facile : un outil de sauvegarde sait écrire une copie quelque part et afficher un rapport vert. Ce qui est difficile, c'est de s'assurer que cette copie sera lisible, complète et hors d'atteinte le jour où l'original aura disparu.
Trois copies, deux supports, une ailleurs
La règle est ancienne et elle n'a pas vieilli : trois exemplaires de vos données, sur deux types de supports différents, dont un hors du site qui les produit. Ce n'est pas un dogme, c'est la description des trois façons de perdre un fichier : l'effacer, perdre le support qui le porte, perdre le lieu où ce support se trouve. Chaque exemplaire répond à l'une d'elles ; c'est leur cumul qui couvre les trois, jamais un exemplaire pris isolément.
Cette règle décrit un résultat à atteindre, pas notre offre. Ce que nous exploitons, c'est l'exemplaire hors site — celui que personne ne regarde, parce qu'il ne sert jamais, jusqu'au jour où il est le seul qui reste. Vos données quittent vos murs et rejoignent les salles où nous conservons la sauvegarde externalisée : elles n'y partagent ni le matériel, ni l'alimentation, ni le sort de ce qu'elles protègent. Lorsque vos accès sont chez nous, elles y arrivent par notre propre réseau plutôt que par l'internet public.
Un instantané n'est pas une sauvegarde
Les deux mots servent trop souvent l'un pour l'autre. Un instantané fige l'état d'une machine sur la plateforme qui l'héberge : il se prend en un geste, il se rejoue aussi vite, et il vous tire d'une mise à jour ratée là où une restauration serait disproportionnée. Nous en fournissons avec chaque machine — c'est décrit dans notre rubrique VPS.
Mais il vit sur le stockage de la machine dont il est issu, sous la même console et sous les mêmes identifiants. Il ne protège donc ni du sinistre, ni de la disparition de la plateforme elle-même, ni de l'attaquant qui a obtenu les droits d'administration. La sauvegarde commence exactement là où l'instantané s'arrête : ailleurs, sur un autre support, sous une autre autorité.
Une copie qu'un attaquant peut effacer n'en est pas une
Les rançongiciels ne se contentent plus de chiffrer les données. Ils cherchent d'abord les sauvegardes, parce qu'une victime capable de restaurer ne paie pas. Ils suivent les partages montés, les identifiants enregistrés dans l'outil de sauvegarde, les consoles restées ouvertes ; puis ils effacent, et ils attendent qu'on s'en aperçoive.
C'est pourquoi nos copies sont immuables : une fois écrite, une version ne peut plus être modifiée ni supprimée avant l'échéance que vous avez fixée. Ni par un compte compromis, ni par un administrateur pressé, ni par nous. Cette contrainte est inconfortable — personne ne peut se raviser — et c'est précisément ce qui lui donne sa valeur.
Ce que nous ne pouvons pas faire
- Lire vos sauvegardes : elles nous arrivent déjà chiffrées.
- Supprimer une version avant son échéance, même si vous le demandez.
- Restaurer ce qui n'a jamais été inscrit au périmètre : cette liste se relit.
- Retrouver votre clé si vous la perdez : nous n'en gardons aucun exemplaire.
- Rattraper ce qui a été écrit entre la dernière copie et la panne.
À quoi ça sert
Quatre situations où tout se joue sur la restauration
Ce sont les appels que nous recevons, et ils commencent presque tous par la même phrase.
Un rançongiciel a fait le tour du réseau
Les partages sont chiffrés, les instantanés locaux ont été effacés avec le reste, et l'attaquant avait pris le temps de rester discret. Les versions déjà verrouillées, elles, n'ont pas pu être réécrites : nous repartons de la dernière antérieure à l'intrusion.
Un dossier supprimé sans que personne le voie
La suppression date d'avant les vacances, la corbeille est vide depuis longtemps, et personne ne s'en aperçoit avant de chercher le document. C'est la rétention qui tranche : si elle remonte assez loin, le dossier revient.
Un serveur qui ne redémarre plus
Une mise à jour système, un volume corrompu, et la machine ne repasse pas la main. Nous remontons l'image complète sur du matériel sain, plutôt que de réparer à l'aveugle un système auquel plus personne ne fait confiance.
Une salle entière devenue injoignable
Incendie, dégât des eaux, coupure qui dure : le matériel n'est plus accessible, et le retour à la normale ne dépend plus de vous. Les services repartent des copies externalisées, dans l'ordre décidé avant l'incident, sur la cible prévue pour les accueillir.
Ce qui est inclus
La mécanique du service, pièce par pièce
Ces pièces ne varient pas d'un client à l'autre : elles sont en place dès la mise en service. Ce qui varie, c'est le périmètre, la fréquence des copies et la durée de rétention.
- Le chiffrement. Posé sur vos machines, avant tout départ de données, et maintenu au repos comme en transit.
- L'immuabilité. Chaque version est verrouillée jusqu'à son échéance : ni réécriture, ni suppression anticipée, quel que soit le compte employé.
- La rétention. Décidée périmètre par périmètre, avec des versions plus espacées à mesure que l'on remonte dans le temps.
- Le catalogue des versions. Savoir ce qui existe, à quelle date, et ce que contenait un fichier avant l'incident, sans monter une restauration pour le vérifier.
- La copie cohérente. Bases de données et machines actives sont figées proprement le temps de la copie : sans cela, on sauvegarde un état qui n'a jamais existé.
- La supervision des travaux. Un travail qui échoue, qui déborde de sa fenêtre ou dont le volume s'effondre déclenche une alerte chez nous, pas un courriel de plus chez vous.
- Les essais de restauration. Programmés, réellement exécutés, et suivis d'un compte rendu qui dit ce qui a été remonté, dans quel état, et ce qu'il a fallu pour y parvenir.
- Le plan de reprise. L'ordre de redémarrage des services, leurs dépendances et qui décide quoi : écrit à froid, jamais improvisé pendant l'incident.
| Ce que l'on protège | La question qui tranche | Ce que la réponse change |
|---|---|---|
| Machine virtuelle entière | Faut-il la relancer telle quelle, ou seulement y repêcher des fichiers ? | L'image complète repart d'un bloc ; le fichier par fichier suppose un système déjà debout. |
| Base de données | Peut-on l'arrêter le temps de la copie ? | Sinon il faut une copie cohérente à chaud, faute de quoi on restaure une base écrite à moitié. |
| Serveur de fichiers | Jusqu'où faut-il pouvoir remonter dans le temps ? | C'est la rétention qui décide, et elle se choisit avant l'incident, jamais après. |
| Postes de travail | Que contiennent-ils que rien d'autre ne contient ? | Ce qui n'existe nulle part ailleurs entre au périmètre ; le reste se réinstalle. |
| Configuration des équipements | Sait-on la reconstruire sans l'original ? | Une configuration perdue se repaie en reconstruction à l'aveugle, le plus souvent au pire moment. |
Comment ça se passe
De l'inventaire au premier retour réussi
-
1
On liste ce qui doit revenir, et dans quel ordre
Deux questions par service, et elles ne se confondent pas : combien de temps peut-il rester arrêté, et quelle quantité de travail accepte-t-on de refaire ? La première commande la façon de restaurer, la seconde la fréquence des copies. Nous y répondons avec vous à froid : dans l'urgence, ces deux questions se tranchent mal.
-
2
On met en place, en commençant par la clé
Périmètres, fenêtres de copie, durées de rétention, verrouillage des versions. Le chiffrement est installé chez vous, avant tout transfert : la clé vous appartient, et nous vous montrons comment la conserver ailleurs que dans le système qu'elle protège.
-
3
On restaure avant d'appeler ça une sauvegarde
Nous remontons une machine pour de vrai, nous reprenons un fichier au hasard dans une version ancienne, nous relisons une base puis nous l'interrogeons. Tant que ce retour n'a pas eu lieu, le service n'est pas déclaré en production : nous ne livrons pas une intention.
-
4
On éprouve encore, à intervalles réguliers
Nous supervisons les travaux, nous recommençons les essais de restauration, et nous vous en remettons chaque fois un compte rendu écrit. Un système d'information change sans prévenir : une restauration éprouvée une seule fois ne dit rien de ce que la sauvegarde est devenue depuis.
Questions fréquentes
Ce qu'on nous demande à propos des sauvegardes
Dans la même famille
Ce qui va souvent avec
Passons à la pratique
Décrivez-nous votre situation, nous vous répondrons par une architecture.
Un site à raccorder, un standard à remplacer, des serveurs à déplacer, une sauvegarde à reprendre en main : on regarde ce que vous avez, on dit ce qui tient et ce qui ne tient pas, et on vous laisse repartir avec un plan — même si vous ne le faites pas avec nous.