Bienvenue > Blog sur la sauvegarde et la restauration > Comment sauvegarder Proxmox ? Méthodes de sauvegarde et de récupération de Proxmox

Comment sauvegarder Proxmox ? Méthodes de sauvegarde et de récupération de Proxmox

1 Star2 Stars3 Stars4 Stars5 Stars
(17 votes, moyenne : 5,00 de 5)
Loading...
Mis à jour 9th février 2023, Rob Morrison

La création de sauvegardes efficaces est une pratique essentielle pour presque toutes les entreprises de nos jours, quels que soient les types de données et d’applications avec lesquels elles travaillent. L’environnement virtuel (VE) de Proxmox n’est pas différent à cet égard. Heureusement, l’augmentation rapide de la popularité de Proxmox a conduit à un grand nombre de solutions de sauvegarde tierces qui ont développé un moyen de créer une sauvegarde spécifique à Proxmox, et il y a également quelques moyens intégrés de faire des sauvegardes.

Méthodes de sauvegarde intégrées à Proxmox

Tout d’abord, il est compréhensible que les méthodes de sauvegarde intégrées puissent avoir des limitations et des problèmes de personnalisation. Par conséquent, et en règle générale, toutes les méthodes de sauvegarde intégrées de Proxmox ont tendance à être des sauvegardes complètes. Cela signifie qu’elles sont accompagnées de toutes les limitations inhérentes à l’utilisation de ce niveau de sauvegarde.

Il y a deux façons principales d’initier une sauvegarde intégrée de Proxmox – en utilisant l’interface graphique originale ou via la commande spécifique vzdump dans la ligne de commande. Ces sauvegardes doivent également avoir un stockage de niveau fichier, et les sauvegardes peuvent également être planifiées en utilisant le niveau « Datacenter » dans l’interface graphique.

Proxmox peut fonctionner à la fois avec des VM et des conteneurs – bien qu’il y ait quelques différences en ce qui concerne les différents modes de sauvegarde, malgré le fait qu’il y ait le même trio de modes pour les conteneurs et les VM : mode arrêt, mode suspension et mode snapshot.

  • Le mode arrêt pour une VM est celui qui offre le plus de cohérence parmi les trois, au prix d’une courte période d’arrêt. Comme son nom l’indique, la VM doit être arrêtée avant d’exécuter ce mode de sauvegarde. L’idée pour les conteneurs est la même, mais il y a un potentiel de temps d’arrêt prolongé.
  • Le mode suspension d’une machine virtuelle tente de réduire le temps d’arrêt potentiel en n’arrêtant pas complètement la machine virtuelle, mais le temps d’arrêt reste relativement important et la cohérence des données peut en souffrir considérablement, c’est pourquoi cette option n’est généralement pas recommandée. La situation pour les conteneurs est quelque peu différente, puisque ce processus crée une copie des données du conteneur en direct dans un emplacement temporaire, suspend ensuite le conteneur et remplace les fichiers de la première sauvegarde par la copie du conteneur suspendu. Le temps d’arrêt de cette opération est nettement inférieur à celui du mode arrêt, mais elle nécessite un espace libre supplémentaire pour contenir la copie temporaire du conteneur.
  • La méthode Snapshot est probablement l’option la plus intéressante parmi les trois, offrant la possibilité de créer des sauvegardes de VM avec peu ou pas de temps d’arrêt, mais avec un risque d’incohérence de la tâche de sauvegarde. Puisque les données sont copiées à partir d’une VM active, il est possible de copier un fichier à mi-chemin ; c’est pourquoi l’instantané exécute généralement les commandes guest-fsfreeze-freeze et guest-fsfreeze-thaw pour tenter d’atténuer les problèmes de cohérence potentiels. Le processus de création d’un instantané d’un conteneur est pratiquement le même puisque le logiciel de sauvegarde suspend également les opérations à l’intérieur d’un conteneur spécifique et crée ensuite un instantané temporaire de tout le contenu de ce conteneur. L’intégralité du contenu du conteneur est ensuite archivée et le snapshot lui-même est ensuite supprimé.

Le processus de restauration avec les appliances Proxmox intégrées est également relativement simple – il peut être effectué soit via l’interface graphique originale, soit à l’aide de deux commandes différentes :

  • qmrestore – pour restaurer les VMs.
  • pct restore – pour restaurer les conteneurs.

L’un des problèmes potentiels du processus de restauration est qu’il peut sérieusement affecter vos performances globales avec les VM/conteneurs, car il n’y a pas de limite à la quantité de bande passante que les opérations de restauration peuvent prendre. Heureusement, ces limites peuvent être configurées par l’utilisateur. Il existe deux types de limites : par restauration et par écriture sur le stockage.

Per-restore consiste à limiter la bande passante pour une restauration à partir d’une seule archive de sauvegarde, et per-storage write limite la quantité de bande passante utilisée dans le processus d’écriture vers un stockage spécifique.

Noms de fichiers et compression

Certaines des plus récentes versions de vzdump encodent à la fois l’heure de la sauvegarde et le type d’invité dans le nom du fichier. Un exemple d’un tel nom de fichier est montré ci-dessous :


vzdump-lxc-105-2019_05_24-11_08_39.tar

Ce type de dénomination permet de stocker plusieurs sauvegardes différentes dans le même répertoire. Il y a également un certain nombre d’options de rétention disponibles que nous aborderons plus tard.

La compression des fichiers est une autre partie du processus de sauvegarde de Proxmox. Il y a trois algorithmes de compression communément connus : lzo, gzip et zstd. En l’état actuel des choses, zstd est actuellement l’algorithme le plus rapide des trois, puisqu’il supporte le multi-threading. De manière assez surprenante, lzo et gzip sont souvent les choix par défaut dans de nombreux cas et sont plus couramment utilisés en général.

Il existe également un remplaçant de gzip appelé pigz, qui se vante d’avoir des performances améliorées grâce à la possibilité d’utiliser le multi-threading. Le nombre de cœurs/threads utilisés par pigz et zstd peut être ajusté manuellement.

La plupart du temps, il est facile de comprendre quel algorithme de compression a été utilisé en regardant simplement l’extension du fichier de sauvegarde.

  • .zst – compression Zstandard
  • .gz or .tgz – compression gzip
  • .lzo – compression lzo

Si l’extension du fichier de sauvegarde ne correspond pas à l’un des exemples ci-dessus – alors il n’a pas été compressé par vzdump en premier lieu.

Conservation des sauvegardes et exemples

Il y a un certain nombre d’options différentes disponibles quand il s’agit de la rétention des sauvegardes dans Proxmox, voici la liste de toutes ces options :

  • keep-all <boolean> – toutes les sauvegardes sont conservées. Aucune autre option ne peut être définie si cette option est « true ».
  • keep-last <N> – spécifie le nombre de sauvegardes qui seraient conservées, en comptant à rebours à partir de la dernière.
  • keep-hourly <N> – spécifie le nombre d’heures pendant lesquelles vos sauvegardes seraient conservées. S’il y a plus d’une sauvegarde pour une heure, seule la sauvegarde la plus récente est conservée.
  • keep-daily <N> – spécifie le nombre de jours pendant lesquels vos sauvegardes seraient conservées. S’il y a plus d’une seule sauvegarde pour un jour, seule la sauvegarde la plus récente est conservée.
  • keep-weekly <N> – spécifie le nombre de semaines pendant lesquelles vos sauvegardes seraient conservées. S’il y a plus d’une sauvegarde unique pour une semaine, seule la sauvegarde la plus récente est conservée.
  • keep-monthly <N> – spécifie le nombre de mois pendant lesquels vos sauvegardes seraient conservées. S’il y a plus d’une sauvegarde unique pour un mois, seule la sauvegarde la plus récente est conservée.
  • keep-yearly <N> – spécifie le nombre d’années pendant lesquelles vos sauvegardes seront conservées. S’il y a plus d’une sauvegarde pendant un an, seule la sauvegarde la plus récente est conservée.

Toutes les options de rétention sont traitées dans cet ordre, de haut en bas. Chacune de ces options ne couvre que les sauvegardes comprises dans sa période de temps et ne prend pas en charge les sauvegardes qui étaient déjà couvertes par les options précédentes. Les options de rétention de votre choix doivent être spécifiées dans une liste séparée par des virgules, comme dans l’exemple ci-dessous :


# vzdump 777 –prune-backups keep-last=3,keep-daily=13,keep-yearly=9

Nous allons maintenant passer en revue certaines des commandes de sauvegarde habituelles et leurs capacités supplémentaires en ce qui concerne la configuration.


# vzdump 777

Dans l’exemple ci-dessus, nous créons un dump de base d’un invité 777 dans le répertoire de dump par défaut sans aucun snapshot.


# vzdump 777 –mode suspend

Dans l’exemple ci-dessus, nous créons une sauvegarde du même invité en utilisant un instantané, ce qui entraîne un temps d’arrêt minimal.


# vzdump –all –mode suspend –mailto root –mailto admin

Dans l’exemple ci-dessus, nous sauvegardons tous nos systèmes invités et envoyons des courriels de notification aux administrateurs et aux utilisateurs root.


# vzdump 777 –dumpdir /mnt/backup –mode snapshot

Dans l’exemple ci-dessus, nous utilisons la méthode snapshot avec un répertoire de vidage personnalisé.


# vzdump 101 102 103 –mailto root

Dans l’exemple ci-dessus, nous sauvegardons plusieurs invités différents en même temps (101, 102, 103…).


# vzdump –mode suspend –exclude 101,102

Dans l’exemple ci-dessus, nous sauvegardons tous les invités sauf ceux spécifiés (101, 102).


# pct restore 600 /mnt/backup/vzdump-lxc-777.tar

Dans l’exemple ci-dessus, nous restaurons un conteneur vers un nouveau CT 600.


# qmrestore /mnt/backup/vzdump-qemu-888.vma 601

Dans l’exemple ci-dessus, nous restaurons une VM QemuServer en tant que VM 601.

Les méthodes de sauvegarde de Bacula Enterprise pour Proxmox

Heureusement, il existe un bon nombre d’alternatives tierces en ce qui concerne les opérations de sauvegarde et de restauration dans l’environnement virtuel Proxmox. Par exemple, il y a Bacula Enterprise, qui est une solution de sauvegarde complète, capable de travailler avec une myriade de types de bases de données/VM différents, et qui possède également un module Proxmox intégré en natif.

De manière assez surprenante, Bacula Enterprise propose également deux méthodes différentes pour effectuer une sauvegarde de VM Proxmox, et l’une d’entre elles n’implique même pas le module Proxmox en premier lieu.

La première méthode implique l’installation d’un File Daemon Bacula Enterprise sur chacune des VM invitées dont vous souhaitez effectuer la sauvegarde. Notez que vous devrez planifier et établir des priorités si vous utilisez plusieurs VMs avec cette méthode, car les sauvegarder toutes en même temps pourrait facilement créer un goulot d’étranglement pour votre réseau/sous-système de disques.

A part cela, l’installation d’un File Daemon de Bacula permet un large choix de fonctionnalités, y compris la vérification des tâches, la restauration de fichiers individuels, la compression au niveau des fichiers, la vérification des sommes de contrôle, et plus encore.

Comme la seconde méthode de création de sauvegardes Proxmox à l’aide du module Proxmox de Bacula est la plus puissante, nous n’aborderons que les détails et les configurations de ce module spécifique.

Sauvegarde de Proxmox avec Bacula Enterprise

Trois étapes principales sont incluses dans le processus de création d’une sauvegarde de la VM Proxmox avec Bacula Enterprise :

  • Sauvegarde de la configuration de la VM invitée.
  • Création d’un snapshot de la VM invitée.
  • Déchargement des données à l’aide de la commande vzdump.

Comme vous pouvez le constater, le principal mode de sauvegarde utilisé par Bacula Enterprise est le mode Snapshot, ce qui permet des sauvegardes cohérentes et des temps d’arrêt réduits, voire nuls. Les sauvegardes des VM invitées LXC sont stockées dans deux types de fichiers – .tar et .conf, tandis que les VM invitées QEMU utilisent le type de fichier .vma.

Cela ne s’applique qu’à une seule VM invitée, il est donc nécessaire de créer plusieurs tâches de sauvegarde si vous devez sauvegarder plusieurs VM Proxmox. Le processus lui-même est largement automatisé, créant des instantanés et les supprimant après avoir déchargé les données, il est donc relativement simple du point de vue d’un utilisateur régulier.

Restauration de Proxmox avec Bacula Enterprise

Deux types de restauration sont disponibles lorsqu’il s’agit de Proxmox avec Bacula Enterprise. Vous pouvez restaurer les données en tant que VM invitée Proxmox complète (elle sera restaurée soit avec le vmid original avec lequel elle a été sauvegardée, soit avec le nouveau si le précédent est déjà pris). Tout ce que vous avez à faire est d’utiliser le paramètre where= pendant le processus de récupération des données de Bacula.

Une autre nuance concerne le vmid de la VM invitée restaurée. S’il est nécessaire qu’une VM restaurée ait un nouveau vmid, celui-ci est choisi aléatoirement comme un nombre du plus haut vmid disponible +1…11 ajouté à ce nombre. Vous pouvez également passer outre ce processus aléatoire avec la commande sequentialvmid – de cette façon, votre VM invitée obtiendra le premier numéro disponible dans le système.

Une autre option de restauration consiste à restaurer toutes les données dans un répertoire local. Cela peut également être fait avec une commande similaire : where=/some/path. Les chemins inexistants seront automatiquement créés par le module Proxmox.

Conclusion

Bacula Enterprise offre un éventail particulièrement large d’options différentes lorsqu’il s’agit d’opérations de sauvegarde et de restauration, et son module de sauvegarde et de restauration Proxmox n’est pas différent. Le haut niveau de personnalisation se traduit par une sauvegarde particulièrement rapide et (plus important encore) une restauration rapide des données d’une organisation. En utilisant sa technologie avancée de snapshot et en tirant parti de la flexibilité du logiciel dans le processus, Bacula Enterprise est un choix solide pour vos besoins de sauvegarde et de restauration Proxmox.

À propos de l’auteur
Rob Morrison
Rob Morrison est le directeur marketing de Bacula Systems. Il a commencé sa carrière dans le marketing informatique chez Silicon Graphics en Suisse, où il a obtenu de bons résultats dans divers rôles de gestion du marketing pendant près de 10 ans. Au cours des 10 années suivantes, Rob a également occupé divers postes de gestion du marketing chez JBoss, Red Hat et Pentaho, assurant la croissance des parts de marché de ces sociétés bien connues. Il est diplômé de l'université de Plymouth, titulaire d'un diplôme spécialisé en médias et communications numériques, et a suivi un programme d'études à l'étranger.
Laissez un commentaire

Votre adresse email ne sera pas publiée. Les champs requis sont indiqués *