La méthode ssh deja-dup ne fonctionne pas - écrit localement à la place
Après des années de rsync, j'essaie deja-dup. Pas si réussi, jusqu'à présent:
Toutes les tentatives pour qu'il écrive sa sauvegarde via ssh aboutissent à une arborescence de répertoires locaux ouverte dans le répertoire où le serveur deja-dup a été démarré: pour l'enregistrement: user et server sont définis à l'aide de l'utilitaire de configuration , la sauvegarde est supposée aller dans le répertoire /export/dumps/notebookhost/user/deja-dup en utilisant un petit répertoire comme source pour la sauvegarde, à des fins de test ...
résultat: un répertoire ( local de /home/user/sftp:/user/server/export/dumps/notebookhost/user/deja-dup contenant la sauvegarde (imaginez cela dans un programme de sauvegarde du répertoire de base - chaque fois qu'il est appelé, cela alourdirait le répertoire racine avec backup + répertoire racine, jusqu'à ce que la limite du système de fichiers soit atteinte)
L'appel de duplicité à partir de la ligne de commande fonctionne correctement - à l'aide de scp ou de sftp - dès qu'une clé ssh publique sans clé est installée sur l'hôte cible:
duplicity sampledir scp://user@Host//export/dumps/client/home/user/deja-dup/
duplicity sampledir sftp://user@Host//export/dumps/client/home/user/deja-dup/
Mais même après que ces méthodes aient été essayées et vérifiées (et que le désordre local ait été nettoyé), le serveur frontal deja-dup continue de créer des structures de répertoires locaux commençant par "sftp:". chemin local). Le rembourrage avec /- es dans des endroits stratégiques n'a abouti qu'à %2F- es ajouté au chemin.
Si "emplacement personnalisé" est sélectionné, le dernier uri généré pour ssh est affiché comme suit:
sftp://192.168.178.12/export/dumps/client/home/user/deja-dup
il manque dans cet emplacement / pour écrire correctement ailleurs que dans le répertoire utilisateur de l'utilisateur. 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 eu que des répertoires locaux nommés différemment. La citation de l'URI ne fonctionne pas, car dans ce cas, le chemin d'accès au répertoire local local est prédéfini. L'échappement de parties de l'URI ne fonctionne pas non plus - le caractère d'échappement est inséré littéralement dans le nom du répertoire local.
Essayez ensuite: en utilisant dconf-editor pour contourner l'analyse dans l'outil de configuration.
org.gnome.DejaDup.File path 'sftp://user@Host: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 ne donne qu'un nom de répertoire local commençant par un guillemet simple, dès que deja-dup --backup est appelé ...
Le bogue 908791, sauvegarde vers ftp ou sftp, crée le dossier "sftp:" ou "ftp:" dans l'emplacement de lancement de Deja-Dup semble décrire cela depuis déc 2011, mais n'est pas résolu. Le paquet python-paramiko est (a été) installé.
Mise à jour:
Lors de la tentative d'accès au système de fichiers supprimé via sftp dans nautilus (entrez ^ L pour accéder à la barre d'emplacement, entrez sftp://user@Host/export/dumps/client/user/ comme uri, le même chemin étrange /home/user/sftp:/user@Host/.. est construit et fait écho dans le message d'erreur (/home/user étant le répertoire de travail actuel): 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:/user@Host/...': No such file or directory.
Résolu:
La mise à niveau vers 14.04 n'a pas installé sshfs. Ce n'est pas non plus dans les dépendances de deja-dup, et son absence a donc 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. Désormais, deja-dup --backup appelé à partir du 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, voir ma réponse au problème nautilus .
Ce qui précède n'a pas fonctionné pour moi, mais j'ai trouvé un travail un peu maladroit.
le truc que j'ai utilisé est de "monter" le dossier distant et de tromper deja dup en pensant que c'est un dossier local.
Je ne sais pas si je peux établir un lien entre un débutant, mais chercher des disques de montage 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 édition: cela concerne aussi bien smb que ssh, donc je ne pense pas que ce soit limité à une sauvegarde ssh mais à distance.