deja-dup La méthode ssh ne fonctionne pas - écrit localement à la place

4

Après des années de rsync , je donne deja-dup a essayer. Pas si réussi, jusqu'à présent:

Chaque tentative d’écrire sa sauvegarde via les résultats de ssh dans une arborescence de répertoires locale s’est ouverte dans le répertoire où le front deja-dup a été lancé: pour l'enregistrement: user et server sont définis avec l'utilitaire de configuration, la sauvegarde est supposée aller dans le répertoire /export/dumps/notebookhost/user/deja-dup Utiliser un petit répertoire comme source pour la sauvegarde, à des fins de test ...

resultat: un répertoire local de /home/user/sftp:/user/server/export/dumps/notebookhost/user/deja-dup contenant la sauvegarde (imaginez ceci dans une planification de sauvegarde du répertoire personnel - à chaque fois qu’il est appelé, l’hôte contient le répertoire-répertoire backup +, jusqu'à ce que la limite du système de fichiers soit atteinte)

L'appel de la duplicité depuis la ligne de commande fonctionne comme il se doit - à la fois en utilisant scp ou sftp - une fois qu'une clé ssh publique sans clé est installée sur l'hôte cible:

 duplicity sampledir scp://[email protected]//export/dumps/client/home/user/deja-dup/
 duplicity sampledir sftp://[email protected]//export/dumps/client/home/user/deja-dup/

Mais même après l’essai et la vérification de ces méthodes (et le nettoyage local), le frontal deja-dup crée toujours des structures de répertoires locaux à partir de " sftp: " L'omission du nom d'utilisateur dans la configuration entraîne l'omission du nom d'utilisateur dans le chemin d'accès (local). Le remplissage avec / -es dans des endroits stratégiques n'a entraîné que %2F -es ajouté au chemin.

Si "emplacement personnalisé" est sélectionné, le dernier uri généré pour ssh est affiché sous la forme:

sftp://192.168.178.12/export/dumps/client/home/user/deja-dup

/ manque dans cet emplacement pour écrire ailleurs, sauf dans le répertoire principal des utilisateurs. Cependant, il échoue de la même manière que lorsqu'il est sélectionné via l'élément de menu " ssh ". J'ai essayé de remplacer sftp par scp et ssh et je n'ai obtenu que des répertoires locaux nommés différemment. Citer l'URI ne fonctionne pas, car dans ce cas, il obtient le chemin du répertoire local prédéfini. Echapper des parties de l'URI ne fonctionne pas non plus - le caractère d'échappement est littéralement inséré dans le nom du répertoire local.

Essayez ensuite: utiliser dconf-editor pour contourner l'analyse dans l'outil de configuration.

org.gnome.DejaDup.File path 'sftp://[email protected]:22//export/dumps/client/home/user/deja-dup/'

Il est possible d’ajouter des guillemets simples (comme dans toutes les autres chaînes) autour de l’URI. Malheureusement, cela se traduit uniquement par un nom de répertoire local commençant par un seul devis, dès que deja-dup --backup est appelé ...

Bogue 908791 Sauvegarde sur ftp ou sftp, crée le dossier "sftp:" ou "ftp:" dans Deja -Dup Launch Lieu semble décrire cela depuis décembre 2011, mais n'est pas résolu. Le package python-paramiko est (a été) installé.

Mise à jour:

Lorsque vous essayez d’accéder au système de fichiers de suppression via sftp in nautilus (entrez ^ L pour accéder à la barre d’emplacement, entrez sftp://[email protected]/export/dumps/client/user/ comme uri, le même chemin étrange /home/user/sftp:/[email protected]/.. est construit et répercuté dans le message d’erreur) ( /home/user étant le répertoire de travail en cours): Unable to find the requested file. Please check the spelling and try again. Unhandled error message: Error when getting information for file '/home/user/sftp:/[email protected]/...': No such file or directory.

    
posée Tatjana Heuser 02.05.2014 - 20:52
la source

2 réponses

3

résolu:

La mise à niveau vers 14.04 n’a pas installé sshfs . Ce n'est pas dans les dépendances pour deja-dup non plus, et donc son absence a conduit au comportement décrit.

sudo apt-get install sshfs

suivi d'un redémarrage de l'ordinateur portable a résolu le problème. Maintenant, deja-dup --backup appelé depuis le shell entraîne l'envoi de la sauvegarde à l'emplacement correct sur le serveur tel que configuré.

Pour plus d'informations sur le débogage du problème, consultez ma réponse au problème de nautilus .

    
réponse donnée Tatjana Heuser 03.05.2014 - 16:16
la source
0

Ce qui précède n’a pas fonctionné pour moi, mais j’ai trouvé un peu de travail maladroit.

le truc que j'ai utilisé est de "monter" le dossier distant et de piéger deja dup en pensant que c'est un dossier local.

Je ne suis pas sûr que je puisse établir un lien avec un débutant, mais chercher à monter des disques SSH et / ou à le faire via CIFS. Je sais que ce ne sera pas sécurisé en tant que SSH mais sur un petit réseau domestique, cela fonctionne pour moi.

Légère modification: cela affecte aussi bien smb que ssh, donc je ne pense pas que ce soit limité à la simple sauvegarde ssh mais à distance.

    
réponse donnée Stew Fisher 26.05.2015 - 21:36
la source

Lire d'autres questions sur les étiquettes