Pourquoi la sauvegarde d’une machine virtuelle se bloque-t-elle au même pourcentage chaque nuit ?
Une sauvegarde de VM qui se fige chaque nuit au même pourcentage atteint généralement la même région source ou la même phase de sauvegarde, ce qui fait du pourcentage un indicateur de diagnostic reproductible.
Notez le disque exact de la VM, la phase, le message du journal, le débit et l’état de la destination au moment du blocage. Comparez ensuite avec un autre espace de stockage, inspectez le stockage source autour de cette région, distinguez les hooks de mise au repos du système invité du transfert en masse et vérifiez les conflits nocturnes. Ne considérez pas un pourcentage stable comme la preuve d’une défaillance du réseau.
Utilisez le pourcentage comme indicateur de localisation reproductible
Notez le pourcentage exact, le temps écoulé, le disque actuel de la VM, la phase de sauvegarde, le débit de transfert et la dernière ligne du journal sur plusieurs nuits. Le pourcentage indique où se trouve la tâche, mais ne constitue pas à lui seul un diagnostic.
Les travaux d’optimisation de PBS montrent que les goulots d’étranglement des performances de PBS peuvent se déplacer entre les lectures de la source, le hachage, la compression, le transfert réseau et les opérations sur l’espace de stockage. Cartographiez donc le blocage à une phase avant de modifier des paramètres au hasard.
Si la même VM et la même phase s’arrêtent presque au même endroit à chaque exécution, donnez la priorité aux données sources déterministes ou à une étape reproductible du workflow plutôt qu’à une congestion réseau générale.
Comparez la cible de sauvegarde avec une autre destination
Exécutez la sauvegarde de la même VM vers un autre espace de stockage ou une cible locale temporaire si la capacité et la politique de récupération le permettent. Conservez un mode de snapshot et une charge de travail de VM comparables.
Un chemin de stockage de sauvegarde Proxmox courant inclut un stockage NFS ou NAS, et la latence ou le verrouillage de la cible peuvent bloquer une destination tandis que la VM elle-même reste saine.
Si la cible alternative dépasse l’ancien point de blocage, examinez l’espace de stockage d’origine, le système de fichiers, le chemin réseau et l’espace libre. Si les deux destinations se bloquent exactement au même endroit, revenez à la source ou à la phase de sauvegarde.
Vérifiez le disque source autour de la région reproductible
Examinez les journaux de stockage de l’hôte, les données SMART, les erreurs ZFS ou du système de fichiers ainsi que la latence de lecture lorsque la sauvegarde approche du point de défaillance. Une sauvegarde peut être la première tâche à lire chaque bloc froid.
Des témoignages réels sur les goulots d’étranglement prolongés des sauvegardes PBS montrent pourquoi une sauvegarde longue peut être dominée par un seul goulot d’étranglement plutôt que par la taille annoncée de la VM.
Une erreur de lecture, une expiration de délai ou un pic de latence reproductible au même endroit doit faire passer l’incident en mode préservation des données. Évitez les lectures complètes répétées si le disque source se dégrade.
Distinguez la mise au repos du système invité du transfert de données
Notez si la sauvegarde se fige pendant le gel via l’agent invité, la création du snapshot, la préparation des métadonnées ou après le début du déplacement des données en masse. Testez une sauvegarde pendant une fenêtre de maintenance avec une charge minimale sur le système invité.
Le workflow général de sauvegarde Proxmox sépare l’orchestration de la sauvegarde du transfert de stockage. Cette distinction est utile lorsqu’un hook de gel garantissant la cohérence applicative se bloque alors que le débit du disque et du réseau reste normal.
Si la désactivation d’un hook de mise au repos non essentiel du système invité permet à la tâche de continuer, corrigez ce hook ou l’agent invité avant de rétablir l’option de cohérence. Ne laissez pas d’importantes bases de données sans mise au repos sans prévoir une autre stratégie de récupération.
Éloignez la tâche des opérations nocturnes concurrentes
Comparez l’heure du blocage avec les scrubs, la réplication, les analyses de médias, les snapshots, la déduplication ou les tâches de synchronisation cloud. Décalez temporairement une seule tâche concurrente afin de tester la contention.
Une analyse plus approfondie de l’architecture et de l’optimisation de PBS est utile lorsque plusieurs ressources partagent la même fenêtre nocturne et que le pourcentage de sauvegarde indique simplement l’endroit où cette contention devient visible.
Le problème est résolu lorsque la sauvegarde dépasse plusieurs fois l’ancien point de blocage et se termine avec un point de restauration exploitable. Le guide ZimaSpace associé sur la préparation des sauvegardes de VM complète la validation de la récupération ; incluez un test de restauration dans le plan de validation au lieu de vous fier à un indicateur de progression à 100 %.
Produits recommandés
Assistance et conseils
Plus à lire
Plex peut-il partager un GPU avec un autre conteneur Docker ?
Plex et un autre conteneur peuvent souvent accéder au même GPU, mais vous devez tester la prise en charge des pilotes, le mappage des...
Comment déterminer si une erreur Plex vient du client ou du serveur
Reproduisez le même élément sur un autre client, comparez le chemin de session, puis recueillez les preuves côté serveur uniquement après que la portée...
Comment configurer le cache de Plex et le stockage temporaire du transcodage
Protégez l’état persistant de Plex en plaçant les fichiers temporaires de transcodage sur un stockage local adapté, puis vérifiez le nettoyage, l’espace libre et...
