Une copie de sauvegarde ne devient pas hors ligne parce qu’un job se termine avec succès. Elle le devient lorsqu’une copie attendue a été contrôlée, retirée du chemin connecté, identifiée, confiée à une procédure de garde et maintenue récupérable. Dans un scénario Veeam avec un média RDX, le logiciel organise les tâches et les restaurations prévues ; l’équipe doit encore créer et conserver cette séparation physique.
Ce guide ne remplace pas la validation d’une configuration. Avant tout déploiement, version Veeam, système d’exploitation, type de dépôt, interface, modèle RDX, firmware, formatage, chiffrement, rétention et mode de rotation doivent être vérifiés dans la documentation actuelle et sur la page de compatibilité Tandberg Data. L’objectif ici est de concevoir un geste d’exploitation que l’équipe pourra réellement répéter.
Une copie offline est un état opérationnel, pas une étiquette
Un résultat « réussi » indique qu’une tâche a atteint son résultat technique attendu. Il ne prouve pas, à lui seul, que le bon média a été retiré, qu’il est disponible dans un autre contexte ou qu’un autre administrateur saura restaurer depuis cette copie. Inversement, retirer un média sans avoir vérifié ce qui vient d’être écrit peut immobiliser une copie incomplète ou inattendue.
Pour parler de copie hors ligne, l’organisation doit donc pouvoir démontrer quatre choses : le périmètre attendu est présent, le média concerné est bien celui prévu, une autre copie connue reste protégée et le support est sorti du circuit connecté selon un processus de garde. Cette distinction évite de confondre une sauvegarde sur support amovible et une vraie stratégie de reprise.
Définir le rôle de la copie avant de créer un cycle
Commencez par le besoin de restauration. La copie retirée sert-elle à retrouver un fichier, à récupérer un serveur complet, à conserver un point de reprise hebdomadaire ou à disposer d’une copie séparée pendant un incident ? La réponse fixe la fréquence des échanges, la quantité de médias, le délai acceptable pour récupérer le support et la place de cette copie parmi les autres sauvegardes.
Définissez ensuite ce qui fait partie du périmètre : données applicatives, configurations, éléments nécessaires à l’accès et dépendances de restauration. Une carte de contrôle peut relier ce périmètre à une référence de job ou de jeu sans inscrire sur le média de détails sensibles. Le titre du job n’est pas une preuve de couverture ; c’est une aide à la traçabilité qui doit être associée à un test.
Distinguer le rôle du logiciel de celui du média
Dans une architecture Veeam, les jobs, les dépôts, les politiques de conservation et les restaurations relèvent du logiciel et de sa configuration. Un média RDX apporte une unité physique que l’équipe peut identifier, remettre, stocker séparément et réintroduire dans une rotation prévue. Les deux dimensions sont complémentaires, mais aucune n’élimine le besoin de validation.
Cette frontière est importante lorsque l’on parle de « rotated drives ». Les comportements et les limites d’un dépôt configuré avec des disques rotatifs dépendent du produit et de la version Veeam. Le guide de l’éditeur doit être contrôlé avant configuration, surtout pour la rétention, le type de dépôt et les opérations de restauration. Ne transposez pas les paramètres d’un autre environnement et ne supposez pas qu’une référence produit rend une configuration compatible.
Cinq validations avant le premier cycle réel
1. Le scénario est documenté
Écrivez ce que l’on doit pouvoir restaurer, dans quel délai et à partir de quel média. Cette phrase donne une base pour le calendrier de rotation et le test de reprise.
2. La compatibilité est contrôlée pour l’environnement concerné
Vérifiez la configuration projetée avec la documentation Veeam actuelle et la page de compatibilité du site principal : versions, système, repository, interface et matériel. Si un point reste incertain, il faut le résoudre avant de mettre une copie de production en rotation.
3. Le plan de médias laisse une marge
Le cycle ne doit pas forcer l’écrasement d’une copie alors qu’un support est en garde, en transit ou réservé pour un test. Prévoyez les médias nécessaires, une réserve et les règles de retour. Le guide de calcul du nombre de supports complètera cette étape lorsqu’il sera publié dans la même langue.
4. Les responsabilités sont connues
Déterminez qui examine le résultat, qui est autorisé à retirer le média, qui le reçoit hors site, qui surveille les retards et qui remplace ces personnes. Une procédure sans suppléance dépend d’une seule mémoire humaine.
5. La restauration est préparée
Identifiez les prérequis pour récupérer le périmètre : matériel, accès, logiciel, droits, instructions et, le cas échéant, éléments de chiffrement gérés selon les règles internes. Ils ne doivent pas être disponibles uniquement sur le système à restaurer.
La routine : vérifier, retirer, enregistrer, garder, réutiliser
La force d’une copie offline vient d’une suite d’actions courtes et contrôlables.
- Vérifier. Examinez le résultat prévu et les alertes avant de déclarer une copie candidate à la sortie. Un job récent n’est pas automatiquement un jeu validé.
- Préserver. Confirmez qu’une autre copie connue reste disponible pendant le retrait ou un éventuel test. Cela évite de concentrer le risque sur le seul média manipulé.
- Retirer. Retirez le média désigné uniquement lorsque la procédure le permet ; son identifiant doit correspondre à l’enregistrement de la rotation.
- Enregistrer. Notez le média, la référence du jeu, son statut, le responsable, l’emplacement de garde et la date à laquelle une réutilisation sera possible.
- Garder. Confiez la copie au lieu ou à la personne prévue. Une copie qui reste posée près du serveur n’a pas le même rôle qu’une copie réellement séparée.
- Réutiliser avec autorisation. Au retour, contrôlez le registre et le statut du support avant de l’insérer dans le cycle suivant. Un support en retard, suspect ou encore retenu ne doit pas être réemployé par défaut.
Une fiche de contrôle pour la copie retirée
Cette table peut être intégrée dans Gutenberg ou dans le registre interne. Elle ne contient ni secret, ni affirmation de conformité ; elle rend l’état de la copie lisible par une personne de remplacement.
| Point de contrôle | Décision à consigner |
|---|---|
| Média et rotation | Quel identifiant de support a été utilisé ? |
| Jeu de sauvegarde | Quelle référence et quelle date correspondent à la copie ? |
| Résultat examiné | Qui a vérifié le statut attendu et les alertes ? |
| Sortie physique | Quand le média a-t-il été retiré et par qui ? |
| Garde séparée | Quel détenteur ou emplacement en confirme la réception ? |
| Réutilisation | À partir de quelle date et après quel contrôle le média est-il disponible ? |
| Exception | Quel événement impose une action avant le prochain cycle ? |
Réagir aux écarts sans fragiliser la dernière copie
Un média absent, un résultat à investiguer ou une remise hors site retardée sont des situations normales à prévoir, pas des raisons de contourner la rotation. Le processus doit désigner une personne qui qualifie l’écart, utilise une réserve si nécessaire et décide quelle copie reste protégée. L’objectif est de restaurer le cycle sans écraser le dernier jeu connu.
Ne masquez pas un écart en modifiant simplement une étiquette ou en considérant une copie comme offline alors que son emplacement est inconnu. Le registre doit refléter l’état réel. Selon les données et les règles de l’organisation, un événement lié à un média peut aussi exiger une escalade interne spécifique.
Tester depuis le média qui aurait réellement servi
Un test convaincant ne se limite pas à relire le dernier job depuis le système habituel. Sélectionnez périodiquement un média retenu, faites-le récupérer par la procédure prévue, préparez le contexte de restauration et restaurez un périmètre représentatif. Demandez au métier de confirmer que les données ou le service sont utilisables.
Documentez la durée totale, les prérequis rencontrés et les corrections à appliquer. Une copie offline n’est démontrée qu’à travers cette expérience : le média peut être trouvé, son contenu peut être exploité et la reprise ne dépend pas d’une personne ou d’un poste unique.
Pour compléter la méthode, consultez le guide sur l’Air Gap et la checklist de test de restauration. La procédure de stockage hors site sera ajoutée à ce maillage lorsqu’elle sera publiée dans la même langue. Pour valider une référence RDX, une interface ou une configuration Veeam concrète, orientez le lecteur vers les pages Tandberg Data dédiées à Veeam et à la compatibilité.
Partager ce guide
