Principe, configuration et exécution #

La restauration fichier dans Cybee permet de récupérer des fichiers et dossiers spécifiques depuis une sauvegarde, vers un emplacement choisi sur une machine cible.

Comme pour la sauvegarde, elle repose sur la notion de plan, ce qui rend chaque restauration reproductible, traçable et planifiable. Comprendre son fonctionnement permet aux collaborateurs de mener une restauration fiable, du choix du point de restauration jusqu’au suivi en temps réel.

Le plan de restauration : unité de base #

Dans Cybee, une restauration n’est pas une action ponctuelle mais un plan de restauration fichier qui encapsule la configuration nécessaire :

• le dépôt source : là où les sauvegardes sont stockées ;

• le cliché à restaurer : l’identifiant du point de restauration ;

• la destination : chemin absolu sur la machine cible ;

• le (ou les) agents assignés : le serveur qui exécute la restauration (il est possible d’avoir plusieurs serveurs qui exécutent la même restauration en même temps);

• des filtres optionnels d’inclusion / exclusion.

Configurer la restauration #

La configuration technique d’une restauration fichier est portée par pkusieurs paramètres.

Restauration des permissions et ACL Windows  #

Cybee sauvegarde et restaure les métadonnées de sécurité des fichiers en plus de leur contenu. Le comportement standard diffère selon le système.

#

• Restauration des attributs de fichiers Windows standard.

• Prise en charge des descripteurs de sécurité : propriétaire, DACL (droits d’accès) et SACL (audit), ainsi que des attributs étendus.

• La restauration du propriétaire et de la SACL peut requérir des privilèges élevés sur la machine cible (équivalents SeRestorePrivilege / SeSecurityPrivilege).

Cohérence des clichés Windows restaurés (VSS) #

La qualité d’une restauration dépend directement de la qualité du cliché restauré. Sous Windows, les plans de sauvegarde fichier créés par Cybee activent systématiquement l’option VSS, qui s’appuie sur le service VSS (Volume Shadow Copy Service) de Windows.

Au moment de la sauvegarde, le cliché est pris depuis une shadow copy cohérente du volume. Les fichiers verrouillés ou ouverts (bases de données, registre, profils ouverts, fichiers de messagerie…) sont donc capturés dans un état cohérent. À la restauration, ces fichiers sont présents dans le cliché et peuvent être restitués sans l’incohérence qu’aurait provoquée un verrou au moment de la sauvegarde.

• Pour les applications disposant d’un VSS Writer (SQL Server, Exchange, Hyper-V…), la cohérence est garantie au niveau applicatif.

• Pour les applications sans VSS Writer (MySQL, MariaDB, PostgreSQL…), la cohérence applicative repose sur les scripts pre/post backup définis côté sauvegarde — pas sur la restauration.

Exécuter et suivre une restauration fichier #

Le parcours type dans la console Cybee est le suivant :

• Soit on crée un plan de restauration spécifique et on l’exécute

• Soit on lance un plan de restauration fichier déjà existant

En cas de création d’un plan de restauration spécifique, les étapes sont les suivantes

1. Sélectionner le serveur à restaurer

2. Puis sélectionner le plan de sauvegarde fichier existant

3. Lister les clichés disponibles et en choisir

4. Définir le serveur de destination, ajouter d’éventuels filtres.

5. Créer le plan

6. Exécuter la restauration.

L’exécution est asynchrone et le suivi se fait par polling (toutes les 3 à 5 secondes) qui renvoie la progression de la restauration (pourcentage effectué, fichiers restaurés, octets restaurés, …) jusqu’au signal de fin de restauration. Une exécution en cours peut évidemment être annulée.

Cas pratique — Restauration ciblée d’un dossier utilisateur #

Contexte : récupérer uniquement le dossier C:\Users\Admin d’un serveur Windows vers un répertoire de quarantaine, en vérifiant l’intégrité.

{
  "name": "Restauration données PC  Windows",
  "repo_id": "2783d0b1-...-733670bde27b",
  "config": {
    "global_options": { "limit_download": null, "limit_upload": null },
    "snapshot_id": "abc123def456",
    "target": "C:\\RestoreTarget",
    "include": ["C:\\Users\\Admin"],
    "exclude": ["*.tmp"],
    "sparse": false,
    "verify": true
  },
  "schedule_enabled": false
}

Résultat : seuls les chemins de include sont restaurés (hors *.tmp), dans C:\RestoreTarget, avec vérification post-restauration.

Points clés #

• La restauration fichier est encapsulée dans un plan réutilisable et traçable.

• Deux paramètres sont obligatoires : le point de restauration (cliché) et la destination absolue.

• Les filtres include / exclude (et leurs variantes i* insensibles à la casse) permettent une restauration ciblée depuis un cliché complet.

• sparse optimise l’écriture des fichiers « creux » (images disque) ; verify ajoute un contrôle d’intégrité post-restauration au prix d’un temps d’exécution accru.

• Les permissions et ACL sont restaurées par défaut : permissions POSIX + ACL via xattrs sous Linux, descripteurs de sécurité (DACL/SACL) sous Windows — sous réserve de privilèges suffisants et de la version de Restic embarquée.

• Sous Windows, les clichés restaurés sont cohérents au niveau système de fichiers grâce à --use-fs-snapshot (VSS), activé systématiquement dans les plans de sauvegarde Cybee.

• L’exécution est asynchrone : on peut suivre la progression par polling sur l’endpoint status/ jusqu’à la fin de restauration.

• La suppression d’un plan de restauration est possible, contrairement aux plans de sauvegarde.

  #

• Options sparse et vérification après restauration #

Ces deux options de restauration ne sont pas activées par défaut sur Cybee. Elles répondent à des besoins distincts.

Mode sparse (partiellement alloué) #

Lorsqu’un fichier restauré contient de larges plages d’octets nuls (des zéros), le mode sparse demande à Cybee de ne pas écrire physiquement ces zéros sur le disque : le fichier est créé sous forme de fichier creux (sparse file), où le système de fichiers n’alloue aucun bloc pour les régions vides et les enregistre comme de simples « trous ».

• Bénéfice : la taille apparente du fichier reste identique, mais l’espace réellement occupé est moindre et l’écriture est plus rapide.

• Cas d’usage typiques : images disque de machines virtuelles, fichiers de bases de données pré-alloués, images brutes de partitions — autrement dit les gros fichiers comportant beaucoup de zéros.

• Limites : le système de fichiers de destination doit supporter les fichiers creux (c’est le cas de ext4, XFS, Btrfs, NTFS mais pas de FAT). C’est à éviter si l’on a besoin d’un fichier réellement pré-alloué (performances, prévention de la fragmentation).

Vérification après restauration #

Une fois les fichiers écrits dans la destination, l’option déclenche une passe de relecture : les fichiers restaurés sont relus depuis le disque et comparés à ce qui est enregistré dans le cliché.

• Objectif : détecter une corruption ou une écriture incomplète survenue pendant la restauration (problème disque, écriture tronquée). C’est la garantie que ce qui est sur la machine cible correspond bien au cliché.

• Coût : une lecture supplémentaire de l’ensemble des données restaurées, donc un temps de restauration plus long et davantage d’I/O. L’impact est notable sur de gros volumes.

• Périmètre : il contrôle la restauration (cible vs cliché). Il ne vérifie pas l’intégrité du dépôt lui-même, qui relève d’un contrôle distinct.