Utilisation d'Ubuntu 16.04, deja-dup 34.2 et de duplicity 0.7.06.
Pour démarrer une sauvegarde hebdomadaire, j'ai connecté le lecteur externe habituel à l'ordinateur habituel, donné le mot de passe et reçu le message d'arrêt :
La sauvegarde existante est celle d'un ordinateur nommé correctname , mais le nom actuel de l'ordinateur est nomcorrect.lan . Si cela est inattendu, vous devez sauvegarder à un autre emplacement.
Annuler/Continuer
C'est inattendu. Non pas parce que j'ai branché le disque externe sur le mauvais ordinateur, mais parce que le nom de l'ordinateur est effectivement correct. Vérifié avec uname -n .
Je ne suis pas tout à fait enclin à sauvegarder à un autre endroit, car je ne voudrais pas que ce problème se reproduise avec d'autres noms/ordinateurs. Les nouvelles sauvegardes prennent du temps, entre autres considérations.
Les questions se posent :comment se fait-il que le déjà-dup/duplicité compose ce nom ? comment résoudre ce problème ?
Ajoutée. En cliquant sur Continuer, vous effectuez une sauvegarde incrémentielle. Pourtant, le message d'arrêt est un arrêt inutile dans la procédure à éviter si possible.
Réponse acceptée :
Utilisation d'Ubuntu 19.10, déjà-dup 40.1, duplicity 0.8.04.
Les questions se posent :comment se fait-il que deja-dup/duplicité compose ce nom ?
Selon les rapports de bogues (remontant à 2010), il s'agit d'un bogue de duplicité affectant déjà-dup. Duplicity préfère le nom de domaine complet (FQDN) pour le nom de l'ordinateur de la sauvegarde.
- La façon dont la recherche FQDN est effectuée dépend à la fois de la configuration réseau de votre ordinateur et du comportement du réseau auquel l'ordinateur est connecté.
- En particulier, les modifications externes du réseau peuvent donc interrompre les sauvegardes. Cela inclut le déplacement de l'ordinateur d'un réseau à un autre.
Voir
- https://bugs.launchpad.net/deja-dup/+bug/1268182
- https://bugs.launchpad.net/duplicity/+bug/667885
comment résoudre ce problème ?
Les rapports de bogue suggèrent de modifier /etc/hosts de diverses façons. Voici ce que j'ai changé, avec mycomputer étant mon nom choisi. Notez que l'ordre semble important.
/etc/hosts (adresses ipv6 omises)
Original :
127.0.0.1 localhost
127.0.1.1 mycomputer
Modifié :
127.0.0.1 mycomputer localhost
127.0.1.1 mycomputer
Dès que j'ai enregistré le fichier, une sauvegarde automatique a commencé. Cela a fonctionné comme prévu.
Voir
- https://bugs.launchpad.net/deja-dup/+bug/1086068
- Deja Dup résout le nom d'hôte de manière incorrecte, ajoute le nom d'hôte du FAI
- À quoi sert /etc/hosts ?
Mes sauvegardes se sont interrompues au moment où mon FAI a mis à niveau son infrastructure dans ma région vers ipv6. A commencé à voir "nom d'hôte modifié" avec des noms d'hôte tels que dynamic-xxxx-yyyy-zzzz.area-123.example.com .
J'ai essayé de vérifier en rétablissant le fichier et en redémarrant, mais la sauvegarde toujours fonctionne si incertain si c'est réellement corrige le problème, ou déclenche simplement deja-dup/duplicity "dans le bon sens". Peut-être lié aux délais d'attente DHCP (7 jours) dans le routeur appartenant au FAI, ou à un autre paramètre que j'ai modifié. Je poste quand même la réponse, mais je devrai peut-être la réviser si elle cesse de fonctionner dans une semaine.
Connexe :L'installation de Snap ne démarre pas ?Cela fait maintenant plus d'une semaine depuis la rédaction de cette réponse. Le démarrage d'une sauvegarde et la vérification des sauvegardes ont réussi. Également redémarré et lancé une autre sauvegarde, qui a également réussi. Il semble que le correctif suggéré fonctionne jusqu'à présent , du moins pour moi sur ma machine et dans mon environnement réseau.