Objectif
Configurer un job Veeam Backup Copy vers un repository secondaire hors site afin de disposer d’une copie indépendante des sauvegardes primaires, avec une rétention propre, une bande passante maîtrisée et une validation réelle de restauration depuis la copie.
Prérequis
- Job(s) de sauvegarde source ayant déjà produit au moins un restore point valide.
- Repository secondaire ajouté à l’infrastructure Veeam et disposant de la capacité nécessaire.
- Connectivité inter-site testée entre les data movers/repositories concernés.
- Politique de rétention cible définie : court terme et, si nécessaire, GFS hebdomadaire/mensuel/annuel.
- Compte rendu de test de restauration attendu et fenêtre pour exécuter un restore pilote depuis le second site.
Procédure pas à pas
Contrôler les sauvegardes sources et le repository cible
Avant de créer le job, vérifiez que les sauvegardes sources possèdent des restore points récents et sains. Contrôlez l’espace libre du repository secondaire, son type de stockage et son emplacement réel. Une copie vers un second dossier du même stockage ne répond pas au même risque qu’un repository isolé sur un autre site ou un autre domaine de défaillance.
- Les sources possèdent au moins un restore point exploitable.
- La cible est suffisamment indépendante et dimensionnée.
Définir le RPO de copie et la rétention
Décidez quand les nouveaux points doivent être copiés et combien de temps ils seront conservés. En mode Immediate Copy, les nouvelles données sont copiées dès qu’elles apparaissent sur la source. La rétention du Backup Copy est propre au job et peut inclure du GFS. Documentez la durée de conservation ainsi que l’espace estimé avant création.
- Le RPO de copie et la rétention cible sont écrits et validés.
Créer le Backup Copy Job
Dans la vue Home de Veeam Backup & Replication, créez un nouveau Backup Copy Job pour les workloads ou jobs concernés. Donnez-lui un nom explicite incluant le site cible et la criticité. Sélectionnez uniquement les sauvegardes qui doivent être répliquées afin d’éviter de saturer la liaison et le repository avec des données non prioritaires.
- Le job référence les bonnes sauvegardes sources.
Sélectionner le repository du second site
Choisissez le repository cible et vérifiez les paramètres de rétention associés. Si le repository est immuable ou possède des contraintes particulières, vérifiez que la durée de rétention et l’immutabilité ne se contredisent pas. Le job doit pouvoir conserver les restore points demandés sans atteindre prématurément la capacité maximale.
- La destination correspond au second site et la capacité estimée est suffisante.
Configurer la fenêtre de transfert et le chemin réseau
Adaptez les horaires de transport aux contraintes WAN. Sur une liaison partagée, évitez qu’une première synchronisation volumineuse ne sature la production. Si vous utilisez des règles réseau ou des proxies/gateways spécifiques, contrôlez leur placement et la route réelle. Pour un volume initial très important, évaluez les mécanismes de seeding supportés plutôt qu’un transfert incontrôlé.
- Le job possède une plage de transport compatible avec l’usage du WAN.
- Le chemin réseau est identifié et supervisable.
Lancer la première synchronisation et surveiller
Démarrez le job et observez le débit, la quantité de données lues et écrites, les éventuels retries et la durée estimée. Une première copie peut être beaucoup plus longue que les incrémentales suivantes. Ne concluez pas à un échec uniquement sur la durée ; recherchez les erreurs réseau, stockage ou de disponibilité de la source.
- La première session se termine avec succès et crée des restore points sur la cible.
Vérifier la chaîne et la rétention sur la cible
Dans Backups, ouvrez la copie secondaire et vérifiez le nombre de restore points, leurs dates et la cohérence avec la politique du job. Si GFS est activé, contrôlez que les points prévus sont créés au fil des cycles. Comparez l’espace consommé à l’estimation afin de corriger la capacité avant qu’elle ne devienne critique.
- La chaîne de Backup Copy reflète la politique de rétention attendue.
Tester une restauration depuis le second site
Effectuez un restore pilote depuis la copie, pas depuis le backup primaire. Choisissez un fichier, une VM ou un élément représentatif selon votre environnement. Le test doit prouver que la copie est indexée, lisible et utilisable sans dépendre du repository source. Mesurez la durée afin d’évaluer le RTO
- La restauration aboutit depuis le Backup Copy uniquement.
- Le temps de restauration est documenté.
Superviser les retards et la capacité
Ajoutez le job aux alertes de supervision : session en échec, copie en retard, repository bas en espace et absence de nouveaux restore points. Un job configuré mais silencieusement bloqué pendant plusieurs jours ne constitue pas une protection. Vérifiez périodiquement le statut des chaînes et les tests de restauration.
- Les échecs ou retards de copie déclenchent une alerte exploitable.
Validation
La procédure est validée lorsque :
- Le second site contient des restore points distincts du repository primaire.
- La rétention du Backup Copy correspond à la politique définie.
- La liaison inter-site reste dans les limites prévues et le job ne prend pas de retard.
- Une restauration pilote réussit directement depuis la copie secondaire.
Retour arrière
- Désactiver le Backup Copy Job si la liaison ou le stockage cible est saturé, sans supprimer immédiatement la chaîne existante.
- Revenir aux paramètres de rétention précédents si une modification crée une pression de capacité inattendue.
- Retirer la cible du job uniquement après avoir confirmé qu’aucune restauration ou politique de conservation n’en dépend.
- Conserver les sauvegardes primaires intactes pendant toute correction du job de copie.
Dépannage / erreurs fréquentes
- Aucun restore point n’est copié : vérifier qu’un backup source récent existe et que le job référence la bonne source.
- Copie en retard : analyser débit WAN, fenêtre de transport, repository cible et taille des nouveaux blocs.
- Repository cible se remplit trop vite : revoir rétention, GFS, croissance et éventuelle immutabilité avant de supprimer des données.
- Restore depuis la copie échoue : traiter l’intégrité ou l’accès de la chaîne cible avant de considérer le job valide.
- Première synchronisation très longue : distinguer comportement normal lié au volume initial d’un vrai throttling ou d’erreurs réseau.