Serveur de sauvegarde distant ou stockage d’objets cloud pour les sauvegardes de machines virtuelles à domicile

Un serveur de sauvegarde distant est généralement la meilleure cible pour les VM à domicile lorsque vous souhaitez des restaurations complètes rapides, des sauvegardes incrémentielles fréquentes, un comportement prévisible du référentiel et le contrôle de toute la chaîne de récupération. Le stockage objet cloud est généralement plus adapté lorsque la séparation géographique et le fait de ne pas avoir à gérer un deuxième serveur comptent davantage que le contrôle local. Le choix dépend de la taille des restaurations, de la bande passante montante, du comportement de récupération du stockage objet, des exigences d’immutabilité et de la quantité d’infrastructure que vous êtes prêt à exploiter hors site.

Définissez la tâche de récupération des VM avant de choisir la cible

Une sauvegarde de VM n’est pas simplement un dossier de documents. La récupération d’un hyperviseur domestique défaillant peut nécessiter des images disque, la configuration des VM, les métadonnées des invités, les éléments de chiffrement, des notes sur le réseau et un débit suffisant pour reconstruire plusieurs invités volumineux dans le bon ordre.

Proxmox indique que son intégration de sauvegarde peut créer des sauvegardes planifiées de machines virtuelles et de conteneurs, tandis que Proxmox Backup Server ajoute une infrastructure de sauvegarde dédupliquée. Le choix de la cible s’inscrit donc dans un workflow complet de récupération de VM, et non dans un simple stockage de fichiers.

Commencez par définir le résultat attendu : combien de téraoctets doivent être restaurés, dans quel délai la première VM critique doit-elle démarrer et la perte complète du site fait-elle partie du modèle de menace ? Les réponses détermineront si un serveur accessible ou un stockage objet géré par un fournisseur résout la contrainte la plus difficile.

Un serveur de sauvegarde distant est préférable lorsque les grandes restaurations doivent démarrer immédiatement

Un serveur installé dans un autre lieu de confiance peut conserver le format de sauvegarde en ligne et prêt à être restauré, sans attendre la réhydratation d’un niveau d’archivage. Si la liaison intersite est suffisamment rapide, il peut également prendre en charge des sauvegardes incrémentielles fréquentes et la vérification du référentiel avec les mêmes outils que le laboratoire domestique principal.

Ce modèle vous donne un contrôle direct sur le cache, les chemins réseau, la rétention, le remplacement des disques et le logiciel du référentiel. Il est particulièrement utile lorsque vous prévoyez de restaurer des VM entières plutôt que quelques fichiers, car la cible de récupération peut rester accessible en permanence.

Le coût caché est que la « sauvegarde hors site » devient un autre serveur dont vous êtes propriétaire. Quelqu’un doit assurer l’alimentation, le réseau, l’espace physique, les mises à jour, la surveillance, le remplacement des disques et le plan de récupération du nœud distant lui-même. Cette approche n’est intéressante que si ce travail opérationnel apporte un réel avantage en matière de RTO.

Le stockage objet cloud est préférable lorsque la priorité est de supprimer le second site

Le stockage objet remplace le châssis distant, les disques, l’onduleur et la dépendance à un réseau domestique par un service de stockage géré par un fournisseur. Cela peut créer une séparation géographique nette sans demander à un ami ou à un membre de la famille d’héberger une seconde machine.

Amazon S3 prend en charge des règles de cycle de vie qui déplacent ou suppriment les objets de sauvegarde, tandis que d’autres fournisseurs de stockage objet proposent des mécanismes similaires. Le principal gain opérationnel ne réside pas dans la liste des fonctionnalités d’un fournisseur, mais dans le fait que le remplacement des supports et la maintenance du matériel de stockage ne sont plus à votre charge.

Le stockage objet cloud est mieux adapté lorsque la restauration est rare, que l’envoi via le WAN est acceptable et que l’application de sauvegarde peut utiliser le fournisseur en toute sécurité. Il devient moins intéressant lorsque les restaurations complètes de plusieurs téraoctets sont urgentes ou lorsque le comportement de récupération et de transfert réseau du fournisseur domine la fenêtre de récupération.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

La classe de récupération peut modifier le RTO cloud avant même le début du téléchargement

Les objets cloud ne sont pas tous lisibles instantanément. Les classes d’archivage économiques peuvent nécessiter une demande de restauration avant que les données ne soient disponibles. Ainsi, « stocké dans le cloud » ne signifie pas automatiquement « prêt à être retransmis immédiatement ».

AWS documente des délais de récupération allant de quelques minutes à plusieurs heures pour les niveaux d’archivage. Si un référentiel de VM est placé dans une classe d’archivage, ce délai doit être inclus dans le RTO, avant même de commencer à compter le temps de téléchargement depuis Internet.

Utilisez un stockage immédiatement accessible pour les points de récupération qui doivent démarrer rapidement, et archivez uniquement les générations dont le RTO autorise un délai. Si vous avez besoin à la fois du faible coût du stockage en archivage profond et de la rapidité d’un serveur distant prêt à l’emploi, les exigences sont contradictoires et doivent être réparties entre plusieurs niveaux.

L’immutabilité et la séparation des identifiants peuvent inverser le choix le plus sûr

Un serveur distant utilisant les mêmes identifiants administrateur que le laboratoire principal peut être plus facile à gérer, mais aussi plus facile à détruire depuis le même plan de contrôle compromis. Le stockage objet cloud peut créer une séparation plus solide si les verrous de rétention et les identifiants limités sont correctement configurés.

Backblaze documente le verrouillage des objets pour limiter leur suppression ou leur modification pendant la période de rétention, ainsi que des contrôles du cycle de vie. La valeur provient d’une limite de rétention appliquée indépendamment, et non du simple mot « cloud ».

Un serveur distant peut également offrir une séparation solide grâce à des référentiels en ajout uniquement, des comptes distincts, des restrictions de pare-feu et des identifiants de récupération hors ligne. Choisissez l’architecture dont vous pouvez réellement démontrer l’isolation dans un scénario où le système principal est compromis.

L’économie du stockage objet et la politique réseau comptent à mesure que le référentiel grandit

Le cloud évite l’achat de disques, mais introduit des facteurs de facturation tels que la capacité stockée, les opérations, la classe de stockage et parfois la récupération ou la sortie de données. Un serveur distant reporte davantage les coûts au départ : matériel, disques, électricité et main-d’œuvre de remplacement.

Cloudflare R2 publie les éléments de facturation du stockage et des requêtes, ce qui montre pourquoi le stockage objet doit être modélisé comme un service permanent plutôt que comme l’achat ponctuel d’un disque. N’intégrez pas le prix actuel d’un fournisseur dans une architecture destinée à conserver plusieurs années d’historique de VM.

Le serveur distant devient plus intéressant lorsque le volume restauré et les accès répétés augmentent, à condition que le site et le matériel restent fiables. Le cloud devient plus intéressant lorsque le référentiel est principalement écrit une seule fois, rarement restauré, et que la valeur d’éviter un autre système physique est élevée.

Les tests de restauration comptent davantage que l’étiquette de la cible de sauvegarde

Un serveur distant peut tomber en panne silencieusement à cause de disques défectueux, d’identifiants obsolètes, d’une synchronisation interrompue ou de métadonnées de VM manquantes. Le stockage objet cloud peut échouer sur le plan opérationnel à cause d’identifiants expirés, d’un logiciel de référentiel incompatible, de clés de chiffrement oubliées ou d’hypothèses de récupération jamais testées.

La documentation de restauration de restic recommande d’utiliser une restauration complète d’un instantané plutôt qu’un accès limité à la navigation pour les récupérations volumineuses. Le principe s’applique quelle que soit la cible : effectuez un véritable exercice de récupération de VM, et pas seulement une simple liste du référentiel.

La comparaison de récupération ZimaSpace sur les dépendances de récupération d’un hôte utilisant un stockage virtualisé constitue un complément utile. Ne comparez plus les cibles dès qu’une architecture respecte le RTO testé, l’exigence d’isolation et le budget de maintenance, avec un chemin de restauration documenté.

Choisissez la cible qui rend la pire restauration acceptable parfaitement routinière

Choisissez un serveur de sauvegarde distant lorsque les grandes restaurations de VM doivent commencer sans délai d’archivage imposé par le fournisseur, que vous accordez de l’importance à une intégration étroite avec la chaîne de sauvegarde et que vous êtes prêt à entretenir un second système et un second site physiques.

Choisissez le stockage objet cloud lorsque la séparation géographique et la suppression de la maintenance du matériel distant comptent davantage que le contrôle maximal, et lorsque le volume de restauration attendu correspond au modèle d’accès du fournisseur et à votre connexion Internet.

Pour les VM domestiques critiques, une approche hybride peut se justifier : conserver les points de récupération récents sur un serveur distant prêt à l’emploi et les générations immuables plus anciennes dans un stockage objet. N’ajoutez cette complexité que si les deux niveaux répondent à des exigences réellement différentes en matière de RTO ou de défaillance.