Pourquoi un dépôt de sauvegarde dédupliqué passe-t-il en lecture seule après un élagage interrompu ?
Un dépôt peut passer en lecture seule après une opération de purge interrompue lorsqu’un verrou exclusif, une erreur de stockage, un backend immuable ou un état de maintenance incomplet bloque les modifications.
Le mode « lecture seule » peut être une mesure de sécurité du client de sauvegarde plutôt que le véritable mode de montage du système de fichiers. Une purge annulée peut laisser un verrou exclusif, une opération inachevée sur des packs ou des index, un espace de travail de nettoyage insuffisant ou des opérations backend qui autorisent la lecture mais refusent les suppressions. Par ailleurs, le système d’exploitation peut remonter le système de fichiers du dépôt en lecture seule après des erreurs d’E/S ou de cohérence. Identifiez la couche qui refuse la première écriture avant de supprimer des verrous ou de relancer la purge.
Capturez la première opération qui signale le mode lecture seule
Exécutez une commande de liste du dépôt, puis une vérification non destructive, et enregistrez la première erreur dans les journaux du client, du backend et du système d’exploitation.
La documentation de Restic explique que la purge réécrit les données du dépôt et nécessite un accès exclusif, car elle supprime le contenu non référencé et peut reconditionner les fichiers partiellement utilisés.
Si la liste fonctionne mais que toute opération qui crée un verrou ou écrit des métadonnées échoue, faites la distinction entre un verrou obsolète, des autorisations d’écriture du backend et la rétention des objets.
Vérifiez la présence d’un verrou exclusif laissé par la purge interrompue
Répertoriez les verrous du dépôt à l’aide de l’outil de sauvegarde et identifiez, pour chacun, l’hôte, le processus, l’heure de création et la commande qui le détient.
Borg indique que les commandes qui modifient le dépôt utilisent des verrous de dépôt pour empêcher les écritures concurrentes, et avertit que la rupture d’un verrou actif peut endommager l’état du dépôt.
Supprimez un verrou obsolète uniquement avec la commande prévue à cet effet et seulement après avoir prouvé que son détenteur n’existe plus.
Déterminez si le système de fichiers a été remonté en lecture seule
Vérifiez la table de montage, les journaux du noyau, l’état du système de fichiers et du pool de stockage, ainsi que les erreurs récentes liées à l’USB, au SATA, au réseau ou au contrôleur.
La documentation Linux sur ext4 répertorie errors=remount-ro comme une politique de sécurité, ce qui montre comment une défaillance de stockage peut rendre le dépôt réellement accessible en lecture seule.
Ne forcez pas un remontage en lecture-écriture tant que les erreurs matérielles ou du système de fichiers persistent. Conservez les journaux et réparez d’abord le stockage.
Inspectez l’état d’une purge, d’une compaction ou d’un index partiellement exécuté
Déterminez quelle phase a été interrompue : sélection des instantanés arrivés à expiration, suppression des références, reconditionnement des données, reconstruction d’un index ou validation des métadonnées.
La référence de purge de Borg précise que la purge et la compaction sont deux étapes distinctes ; les archives peuvent donc rester valides alors que la récupération d’espace est incomplète.
Utilisez la commande de vérification du dépôt avant une nouvelle opération destructive. Ne supprimez jamais manuellement les packs, les index ou les segments.
Vérifiez le verrouillage des objets, l’immuabilité et les identifiants du backend
Pour les dépôts cloud, examinez la rétention des objets, la conservation légale, la politique du bucket, les autorisations de suppression, la gestion des versions et la rotation des identifiants.
AWS indique que le verrouillage des objets S3 empêche leur suppression ou leur écrasement pendant une période de rétention protégée, ce qui permet les lectures tandis que la purge échoue.
N’affaiblissez pas la rétention immuable simplement pour permettre la réussite de la purge. Utilisez une architecture de dépôt prise en charge par l’outil de sauvegarde.
Vérifiez l’espace libre, les inodes et l’espace de travail de la purge
Vérifiez l’espace en octets du système de fichiers, les inodes, les quotas, les réserves d’instantanés, les répertoires temporaires, les limites du stockage d’objets et l’espace du cache local.
GNU Coreutils explique que df peut afficher l’utilisation des blocs et des inodes, ce qui permet de distinguer un système de fichiers plein d’un verrou ou d’un problème d’autorisation au niveau du dépôt.
Si le système de fichiers est plein, ajoutez temporairement de la capacité ou supprimez des données vérifiées sans rapport avec le dépôt plutôt que de supprimer des objets du dépôt.
Récupérez avec une vérification, un déverrouillage et une seule opération de maintenance contrôlée
Protégez les derniers points de restauration connus comme valides, arrêtez les planifications, exécutez une vérification prise en charge, effacez uniquement un verrou dont l’obsolescence est avérée et effectuez une seule opération de maintenance journalisée.
Le guide ZimaSpace consacré à la récupération d’une destination de sauvegarde pleine fournit la règle complémentaire suivante : traitez un dépôt comme une structure gérée, et non comme un ensemble de fichiers indépendants.
Le problème est résolu lorsque la liste, la vérification, la sauvegarde, la rétention et une restauration de test réussissent toutes sans déverrouillage forcé ni suppression manuelle.
Foire aux questions
Puis-je supprimer manuellement le fichier de verrouillage ?
Pas en première intention. Vérifiez qu’aucun processus ne le détient et utilisez l’opération de déverrouillage prévue par l’outil de sauvegarde.
Dois-je relancer immédiatement la purge après un plantage ?
Non. Vérifiez l’état du dépôt, des index, du système de fichiers et du backend avant une nouvelle opération de maintenance destructive.
Le mode lecture seule signifie-t-il que les données de sauvegarde sont en sécurité ?
Pas nécessairement. Des packs manquants, des erreurs de stockage, des objets immuables ou des index incomplets peuvent toujours empêcher les restaurations.
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...
