Bonjour,
Je me permets ce message car je ne trouve pas l'information sur les forums ovh et launchpad.
Je n'arrive pas à faire la sauvegarde via duplicity dans mes conteneurs PCA et PCS en suivant la procédure :
https://docs.ovh.com/gb/en/storage/pca/duplicity/
Infos :
Centos 8
Duplicity 0.8.11.1596
Voici la commande que je lance :
> duplicity --verbosity debug --encrypt-key "$enc_key" --copy-links --sign-key "$sign_key" --num-retries 3 --asynchronous-upload --volsize 250 --file-prefix-manifest 'hot_' --file-prefix-signature 'hot_' --file-prefix-archive 'cold_' "$src" "multi://$HOME/script/backup/config.json?mode=mirror&onfail=abort"
Le fichier config.json est celui récupéré sur le tuto ovh (en l'adaptant bien sûr avec mes valeurs) :
> [
> {
> "description": "Cold storage",
> "url": "pca://backup-photos_cold",
> "env": [
> {
> "name": "PCA_AUTHURL",
> "value": "https://auth.cloud.ovh.net/v3"
> },
> {
> "name": "PCA_AUTHVERSION",
> "value": "3"
> },
> {
> "name": "PCA_PROJECT_DOMAIN_NAME",
> "value": "Default"
> },
> {
> "name": "PCA_TENANTID",
> "value": "mon_tenant_id"
> },
> {
> "name": "PCA_USERNAME",
> "value": "mon_utilisateur_openstack"
> },
> {
> "name": "PCA_PASSWORD",
> "value": "mon_password_openstack"
> },
> {
> "name": "PCA_REGIONNAME",
> "value": "SBG"
> }
> ],
> "prefixes": ["cold_"]
> },
> {
> "description": "Hot storage",
> "url": "swift://backup-photos_hot",
> "env": [
> {
> "name": "SWIFT_AUTHURL",
> "value": "https://auth.cloud.ovh.net/v3"
> },
> {
> "name": "SWIFT_AUTHVERSION",
> "value": "3"
> },
> {
> "name": "SWIFT_PROJECT_DOMAIN_NAME",
> "value": "Default"
> },
> {
> "name": "SWIFT_TENANTID",
> "value": "mon_tenant_id"
> },
> {
> "name": "SWIFT_USERNAME",
> "value": "mon_utilisateur_openstack"
> },
> {
> "name": "SWIFT_PASSWORD",
> "value": "mon_password_openstack"
> },
> {
> "name": "SWIFT_REGIONNAME",
> "value": "SBG"
> }
> ],
> "prefixes": ["hot_"]
> }
> ]
Voici l'erreur que j'ai :
> Writing cold_duplicity-full.20200308T151355Z.vol1.difftar.gpg
> Backtrace of previous error: Traceback (innermost last):
> File "/usr/local/lib64/python3.6/site-packages/duplicity/backend.py", line 376, in inner_retry
> return fn(self, *args)
> File "/usr/local/lib64/python3.6/site-packages/duplicity/backend.py", line 547, in put
> self.__do_put(source_path, remote_filename)
> File "/usr/local/lib64/python3.6/site-packages/duplicity/backend.py", line 533, in __do_put
> self.backend._put(source_path, remote_filename)
> File "/usr/local/lib64/python3.6/site-packages/duplicity/backends/pcabackend.py", line 153, in _put
> self.conn.put_object(self.container, self.prefix + remote_filename,
> TypeError: must be str, not bytes
> Attempt 1 failed. TypeError: must be str, not bytes
Je ne sais plus quoi faire pour débug le truc.
Merci par avance pour votre aide.
Cordialement,
Stockage et Sauvegardes - Duplicity & pca : Echec Backup (TypeError: must be str, not bytes)
Related questions
- Hubic - Comment récupérer ses fichiers avec une méthode qui fonctionne ?
23541
29.05.2018 17:47
- Nextcloud sur ovh
22765
19.07.2017 18:30
- Help object storage avec api s3
19172
14.11.2018 17:37
- Client hubic Linux encore supporté ?
18374
10.07.2017 17:17
- Sauvegardes Public Cloud Archive et duplicity/deja-dup
16599
04.08.2017 18:45
- Recuperer ses données sur HUBIC
16038
08.02.2017 13:43
- Hubic connexion impossible a mon compte?
13867
20.12.2017 08:23
- [Résolu] Comment s'authentifier sur Cloud Archive ?
13062
30.10.2019 17:45
- Comment se connecter à HUBIC avec Cyberduck
12977
14.08.2018 17:12
- Sauvegarde automatique base de donnée
12341
08.04.2017 05:30
Même problème.
J'ai créé un bug : https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/1867435
Avec la correction de https://bugs.launchpad.net/bugs/1867742 ça fonctionne pour moi avec le dernier daily build.
Bonjour,
Ma réponse est un peu tardive, mais je n'ai pas eu le temps de me remettre dessus.
Merci Xavier pour votre réponse et effectivement, cela fonctionne un peu mieux mais j'ai encore un soucis.
J'arrive bien à faire les backup maintenant avec la version 0.8.12 (disponible dans le dépôt epel de centos 8) mais la restauration ne fonctionne pas.
J'ai testé en Object Storage depuis cette doc et ça fonctionnait bien
https://www.arsouyes.org/blog/2020/17_backup_OVH/
J'ai donc fait un mix des 2 docs suivantes :
https://docs.ovh.com/gb/en/storage/pca/duplicity/ https://www.arsouyes.org/blog/2020/17_backup_OVH/
https://docs.ovh.com/gb/en/storage/pca/duplicity/ https://docs.ovh.com/gb/en/storage/pca/duplicity/
Voici les erreurs :
> MultiBackend: pca://backup-photos_cold: 1 files
> MultiBackend: swift://backup-photos_hot: 2 files
> MultiBackend: pca://backup-photos_cold: 1 files
> MultiBackend: swift://backup-photos_hot: 2 files
> Les métadonnées locales et distantes sont déjà synchronisées. Aucune synchronisation nécessaire.
> Date de la dernière sauvegarde complète : Mon Jul 13 18:30:22 2020
> Données non valides - empreinte SHA1 non vérifiée pour le fichier :
> cold_duplicity-full.20200713T163022Z.vol1.difftar.gpg
> Empreinte calculée : da39a3ee5e6b4b0d3255bfef95601890afd80709
> Empreinte du fichier manifest : 2fa9de527c412b2161f58d7e57ec0ecfa33a6825
Je comprend que le problème se situe au niveau de la signature du fichier. Par contre, une fois que le fichier est dégeler, si je relance la restauration : **ça marche**.
Mais du coup il me faudrait dégeler tous les fichiers manuellement avant de lancer la commande ...
Avez-vous une idée ?
Merci par avance.
Re bonjour,
Et je viens de faire le test avec Duplicity 0.8.14 et c'est pareil.
Lors de la première passe, duplicity lance le dégèle, attend qu'il soit dégelé mais l'empreinte ne correspond pas.
Lors de la deuxième passe (fichier déjà dégelé) ca passe et restaure les données.
Merci par avance pour votre aide.
Salut @YannP15
Merci pour cet article intéressant :)
Pour l'erreur que tu reçois, ce n'est pas déconnant au final.
Sur PCA, le premier GET que tu fais tombe en erreur mais initie le dégel.
Donc, quand duply cherche a lire l'empreinte il n'y parviens pas car n'a (au final) aucun accès au fichier.
Une fois le dégel fait, il a accès a toutes les data (pendant 24h) et tu n'a donc plus l'erreur.
Si tu fais la même chose sur un container PCS tu n'auras pas le soucis :)
Je pense pas que tu puisses faire quoi que ce soit d'autre a mon avis vu que c'est un "soucis" intrinsèque a l'offre.
Jalinn