Dietpi: Problème avec cron et sauvegarde automatique (à partir de v6.10-6.11)?

@eljotx
Je vous remercie pour votre rapport.

G_USER_INPUT=0 devrait être détecté automatiquement lors des exécutions cron, donc pas nécessaire d'attribuer. Mais si vous voulez qu'il ait un effet, vous devez l'exporter, ce qui vaut bien sûr la peine d'essayer:
export G_USER_INPUT=0

Sur les exécutions non interactives, le script se ferme si (près de) un espace libre insuffisant est détecté sur le lecteur cible: https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-backup#L456
Mais vous dites que l'exécution manuelle fonctionne bien? En cas d'espace libre insuffisant, vous verrez l'invite whiptail qui vous donne le choix d'ignorer ou de quitter.

À propos des entrées de journal, des codes de couleur cryptiques + checking for elevation root access sont attendus. Essayer:
cat /mnt/rpi/backup.log
pour avoir les codes couleurs actifs et donc le journal formaté. Veuillez également fournir cette sortie ici, afin que nous puissions vérifier à quel stade le problème s'est produit.

Le script fonctionne bien lorsque je l'exécute manuellement.

Étrange.

Essayez d'exécuter la tâche cron et collez les résultats du journal /mnt/rpi/backup.log

NB: dietpi-backup renvoie automatiquement rsync dans le fichier journal /var/log/dietpi-backup.log , vous pouvez également l'utiliser.

Donc, j'essaye d'exécuter le travail cron sans G_USER_INPUT = 0 (j'ai supprimé ceci du script) et ...

Mon fichier journal de sauvegarde de /mnt/rpi/backup.log
[90m[[0m[33m......[90m][0m Checking for (elevated) root access[0m

dietpi-backup.log est vide

Je n'ai vu aucun processus actif après le démarrage de cron.

Donc, j'ai ajouté au test d'un autre script, pour voir la sortie dans le fichier après le démarrage de cron:

#!/bin/sh

echo 'Cron works!' > /mnt/rpi/cronworks.log

mais ce script n'a pas démarré - il n'y a pas de fichier "cronworks.log" dans / mnt / rpi /
c'est étrange car il y a un fichier de sortie (backup.log) de mon script avec sauvegarde (du 1er mon post), mais non de ce simple

@eljotx
D'accord, il semble y avoir au moins aussi bien une erreur avec cron. Notez que cron démarre les scripts via run-parts /etc/cron.X/script et il y a quelques règles, par exemple les scripts doivent appartenir à root (AFAIK) et plus sûr que les scripts ne sont pas autorisés à avoir des fins de fichier. Cela signifie que /etc/cron.daily/script.sh sera ignoré, le nom doit être /etc/cron.daily/script place.

Cela ne devrait pas non plus être nécessaire, mais essayez d'utiliser #!/bin/bash comme shebang lors de l'utilisation avec des scripts DietPi. Ceux-ci eux-mêmes ont #!/bin/bash , mais pour être sûr, essayez de l'utiliser également dans le script cron.

Le script avait toujours un nom "backup" (sans .sh), je change "#! / Bin / sh" en "#! / Bin / bash" dans le script aussi, et ce script appartient à root. Mon script "test" du dernier message fonctionne maintenant aussi.

J'ai tout essayé, mais ne fonctionne toujours pas. Je change le script pour imprimer dans le fichier journal après avoir terminé un travail et j'ai vu que le script démarre, mais la sauvegarde n'est ni commencée ni terminée (dietpi-backup.log est vide), car je ne peux pas passer au travail suivant comme tar, rclone, etc. Et aussi après avoir exécuté cron, j'ai vu le processus / usr / sbin / cron -f fonctionner et -bash - c'est normal?

Le script fonctionne toujours si je l'exécute manuellement - mais lorsque la sauvegarde est terminée, je dois cliquer sur OK et Annuler (écrans whiptail), et après cela - les travaux suivants commencent.

Je pense que ce problème est lié à l'utilisation de dietpi-backup pour la sauvegarde automatique démarrée par cron. Cela a fonctionné sur la version 6.9, mais n'a pas fonctionné après la réécriture de Dietpi-backup.

@eljotx
Encore une fois, juste pour être sûr:

• Si vous exécutez manuellement /DietPi/dietpi/dietpi-backup 1 est exécuté avec succès?
• Si vous exécutez G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1 fonctionne également sans aucune erreur, affichant quelque chose comme:
  

root@VM-Jessie:~# G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1
[  OK  ] Root access verified.
[  OK  ] DietPi-Drive_Manager | RootFS R/W access verified.

[  OK  ] DietPi-Backup | Checking for pre-req APT packages: rsync
[ INFO ] DietPi-Backup | Flagged for installation: rsync
[  OK  ] DietPi-Backup | APT installation for: rsync, please wait...
Selecting previously unselected package rsync.
(Reading database ... 36227 files and directories currently installed.)
Preparing to unpack .../rsync_3.1.1-3+deb8u1_amd64.deb ...
Unpacking rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...
Setting up rsync (3.1.1-3+deb8u1) ...
Processing triggers for systemd (215-17+deb8u7) ...

[  OK  ] DietPi-Backup | G_AGI: rsync

 DietPi-Backup
─────────────────────────────────────────────────────
 Mode: Backup

[  OK  ] DietPi-Backup | DietPi-Userdata validation: /mnt/dietpi_userdata
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | occ maintenance:mode --on
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : sonarr
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php5-fpm
[  OK  ] DietPi-Services | stop : mysql
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Services | stop : sonarr
[  OK  ] DietPi-Services | stop : lighttpd
[  OK  ] DietPi-Services | stop : php5-fpm
[  OK  ] DietPi-Services | stop : mysql
[ INFO ] DietPi-Backup | Backing up to: /mnt/dietpi-backup
[  OK  ] DietPi-Backup | Free space check: path=/mnt/dietpi-backup/data | available=5695 MB | required=1861 MB
[  OK  ] DietPi-Backup | rsync -aH --delete --delete-excluded --exclude-from=/tmp/.dietpi-backup_filter_inc_exc -v --log-file=/var/log/dietpi-backup.log / /mnt/dietpi-backup/data/
[ INFO ] DietPi-Backup | Backup Completed:

Backup was saved to:
- /mnt/dietpi-backup
- Log file: /var/log/dietpi-backup.log
[ SUB1 ] DietPi-Services > start
[  OK  ] DietPi-Services | start : mysql
[  OK  ] DietPi-Services | start : php5-fpm
[  OK  ] DietPi-Services | start : lighttpd
[  OK  ] DietPi-Services | start : sonarr
[  OK  ] DietPi-Services | start : cron
[ SUB2 ] DietPi-Process_tool > Apply
[  OK  ] DietPi-Process_tool | Completed
[  OK  ] DietPi-Services | occ maintenance:mode --off

• Exécution de la ligne de commande exacte à partir du script

/DietPi/dietpi/dietpi-backup 1 > /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: -L >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz >> /mnt/rpi/backup.log && reboot

fonctionne également, montrant que tout a été exécuté et terminé en /mnt/rpi/backup.log ?

• run-parts --test /etc/cron.daily répertorie votre script (s'il est quotidien, sinon ajustez)
• /usr/sbin/cron -f + -bash est attendu oui, car il démarre un environnement bash à cause de #!/bin/bash .

Si tout ce qui précède est vrai, pouvez-vous essayer de démarrer manuellement les run-parts et voir s'il s'exécute comme prévu:

• Déplacez / copiez le script dans un dossier séparé, par exemple ~/testdir/backup
• Puis run-parts ~/testdir

J'ai testé comme vous le montrez et sur chaque question: oui, tout fonctionne quand je le lance manuellement.
Je l'ai testé avec la commande run-parts, mais cela fonctionne toujours - quand je le fais manuellement.

Mon script est listé après utilisation run-parts --test /etc/cron.daily

Si j'ajoute G_USER_INPUTS = 0 et démarre le script manuellement, dois-je voir les écrans (whiptail) avec des informations sur le journal, etc.? Parce que je le vois toujours.

@eljotx
G_USER_INPUTS=0 désactive simplement l'affichage des menus de whiptail. Les informations sont simplement affichées sous forme de messages du terminal et les questions reçoivent une réponse "non" (annulation en cas de vérification d'espace libre insuffisant, pas de vue du journal).

Pour le forcer pour le script, vous devez soit l'exporter avant d'exécuter le script:

#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1

ou plus facile, donnez-le directement: G_USER_INPUTS=0 /DietPi/dietpi/dietpi-backup 1

Je viens de reconnaître que vous avez utilisé G_USER_INPUT=0 ci-dessus sans S , il doit être G_USER_INPUTS=0 avec S .

Mais si ce n'est pas la variable est exportée, les scripts détermineront si les entrées utilisateur peuvent être effectuées ou non. Dans les exécutions d'unités cron et par exemple systemd, tous les scripts DietPi doivent automatiquement déterminer et affecter G_USER_INPUTS=0 .
Vous pouvez vérifier que notre méthode fonctionne, en ajoutant au début de votre tâche cron (ou une tâche de test):
[[ -t 0 ]] && echo 'This environments allows user inputs' > /mnt/rpi/inputs.log || echo 'This environment does not allow user inputs' > /mnt/rpi/inputs.log
Lors de l'exécution manuelle du script, il doit indiquer que les entrées utilisateur sont autorisées (les menus whiptail s'affichent), s'il est démarré via cron, alors il ne devrait pas, et aucun menu whiptail ne doit bloquer le script.

Je teste d'abord G_USER_INPUTS=0 et si je lance le script manuellement, je consigne:
This environments allows user inputs
sinon si commencer par cron:
This environment does not allow user inputs

Ensuite, j'essaye de changer mon script en ceci:

#!/bin/bash
export G_USER_INPUTS=0
date > /mnt/rpi/backup.log && /DietPi/dietpi/dietpi-backup 1 && (echo "Backup: DONE. " >> /mnt/rpi/backup.log && tar zcfv /mnt/rpi/backup.tar.gz /mnt/backup/dietpi-backup/ && echo "Tar backup: DONE. " >> /mnt/rpi/backup.log && rclone copy /mnt/rpi/backup.tar.gz dysk: && echo "Copy to GDrive: DONE. " >> /mnt/rpi/backup.log && rm -r /mnt/rpi/backup.tar.gz && echo "Remove tar: DONE." >> /mnt/rpi/backup.log && reboot) || echo "Backup failed!" >> /mnt/rpi/backup.log

et dietpi-backup.log est toujours vide, mais backup.log:

lorsque cron a démarré et démarre automatiquement ce script:

pon, 9 lip 2018, 18:54:01 CEST
Backup failed!

quand j'ai démarré le script manuellement:

pon, 9 lip 2018, 18:58:40 CEST
Backup: DONE.
Tar backup: DONE.
Copy to GDrive: DONE.
Remove tar: DONE.

C'est très ennuyeux ... ensuite, mon script n'a que:

#!/bin/bash
export G_USER_INPUTS=0
/DietPi/dietpi/dietpi-backup 1

et ne fonctionne toujours pas si ce script est lancé par cron.

Le problème est toujours avec dietpi-backup lancé par cron à partir de la v6.10. Je pense que c'est un problème avec les changements que vous avez apportés à la v6.10 dans le script dietpi-backup.

dietpi-backup.log est toujours vide

@eljotx
Merci pour vos efforts de test.
Je vais passer en revue notre changé. Je n'ai aucune idée pour l'instant. Au moins d'après vos tests, le script ne se bloque pas (whiptail / G_USER_INPUTS n'est pas le problème), mais échoue.

Fait quelques propres tests:

[......] Checking for (elevated) root access

Après avoir commenté la vérification de l'utilisateur root, dans dietpi-backup , son exécution via cron conduit à:
[FAILED] RootFS is currently Read Only, unable to continue.
Mais:

root@VM-Jessie:~# G_CHECK_ROOTFS_RW
[  OK  ] Root access verified.
[  OK  ] DietPi-Drive_Manager | RootFS R/W access verified.

@eljotx

tput est le problème:
tput: No value for $TERM and no -T specified

• Intéressant, comme nous l'avons appelé avec la v6.9 également 🤔.

Correction: https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090

Ce patch corrige également un autre problème: "run_ntpd 1" exécuté par cron tous les jours ou toutes les heures ne synchronise pas l'heure (l'horodatage de / var / lib / systemd / clock ne change pas).

@kmakisara
Jep vous avez raison, cela a du sens.
Juste pour éviter la modification manuelle du script pour appliquer le correctif, tous ceux qui ont le même problème devraient faire: wget https://raw.githubusercontent.com/Fourdee/DietPi/82ac7b32d32dca9db4fdb824c7ead80174844090/dietpi/func/dietpi-globals -O /DietPi/dietpi/func/dietpi-globals

Je pense que certaines de nos questions ouvertes sont liées à cela. Si run_ntpd dans cron.hourly échoue, dietpi-logclear ne sera pas appelé par la suite, ce qui entraînera le remplissage de / var / log: https://github.com/Fourdee/DietPi/issues/ 1920

Je me demande simplement pourquoi ce problème est apparu en premier avec la v6.10 +, car nous utilisions déjà tput auparavant dans nos tâches cron.
Peut-être que quelqu'un peut trouver le changement qui a causé les problèmes, afin que nous sachions comment mieux nous en occuper à l'avenir:

• Appel de la notification de processus animée v6.9: https://github.com/Fourdee/DietPi/blob/7b682286e72ef339518d110892a54e7ce405b648/dietpi/func/dietpi-globals#L301 -L315
• Modifications apportées avec la v6.10: https://github.com/Fourdee/DietPi/pull/1867/files
• tput cuu et tput cols sont appelés dans les deux cas, ainsi que tput ed sur chaque autre notification DietPi lors de la suppression de l'animation de traitement.
• Ce ne sont peut-être pas les modifications apportées aux notifications qui ont causé le problème, mais les erreurs de gestion cron (ou tput) différemment après certaines mises à jour.

Autres tests à ce sujet:

root@VM-Stretch:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root@VM-Stretch:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified

• $TERM sur cron est défini sur dumb
• tput prétend qu'il n'y a aucune valeur pour la variable, même si elle est invalide.

root@VM-Stretch:/tmp# TERM='dumb' tput cols
237
root@VM-Stretch:/tmp# export TERM='dumb' tput cols
root@VM-Stretch:/tmp# export TERM='dumb' tput cols && echo continue
continue

• Comme $ TERM invalide ne conduit à aucune erreur (ne conduit simplement à aucune sortie de sortie), l'erreur de sortie cron semble être liée à l'absence de -T , [[ -t 0 ]] entraîne un faux. Peut-être que cela s'est comporté différemment avant. Dernière mise ncurses-bin jour de http://ftp.de.debian.org/debian/pool/main/n/ncurses/

• Nous avons déjà eu des problèmes avec des terminaux non interactifs / invalides, alors quittez maintenant les scripts dietpi- *, si $ TERM vide ou ' unknown ' est trouvé: https://github.com/Fourdee/DietPi/blob/ testing / dietpi / func / dietpi-globals # L30 -L35

• Une enchère incohérente, car nous pourrions vouloir autoriser les exécutions non interactives (également sans terminal connecté), mais nous devons faire attention à appeler tput respectivement d'autres commandes nécessitant un terminal valide.

Test sur v6.9:

root<strong i="6">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• Une erreur apparaît, mais le script reprend.

La mise à jour APT ne contient pas de cron et / ou ncurses (réduction par des packages non liés testés):

• Même après apt-get dist-upgrade et redémarrage, cron n'arrête pas l'exécution après une erreur de tput:

root<strong i="15">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="16">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• dietpi-update au maître v6.11: Veeery étrange, toujours pas de problème ...

root<strong i="22">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
finish

• Ajout de l'exécution de Dietpi-backup:

root<strong i="27">@DietPi</strong>:/tmp# cat /etc/cron.minutely/test
#!/bin/bash

echo "$TERM" &> /tmp/cron.test
[[ -t 0 ]] && echo 'interactive' &>> /tmp/cron.test
tput ed &>> /tmp/cron.test
/DietPi/dietpi/dietpi-backup 1 &>> /tmp/cron.test
echo 'finish' &>> /tmp/cron.test
root<strong i="28">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
[......] Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 266: ( 38 + 6 ) /  : syntax error: operand expected (error token is "/  ")
finish

• Le script échoue mais le travail cron continue. Test avec dietpi-globals v6.9:

root<strong i="34">@DietPi</strong>:/tmp# cat cron.test
dumb
tput: No value for $TERM and no -T specified
         Checking for (elevated) root accesstput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
tput: No value for $TERM and no -T specified
[  OK  ] Root access verified.
         DietPi-Run_ntpd | systemctl restart systemd-timesyncdtput: No value for $TERM and no -T specified
/DietPi/dietpi/func/dietpi-globals: line 308: ((: lines=(38+6)/ : syntax error: operand expected (error token is "/ ")
[..    ] tput: No value for $TERM and no -T specified
[  OK  ] DietPi-Run_ntpd | systemctl restart systemd-timesyncd
[ INFO ] DietPi-Run_ntpd | NTPD: Waiting for completion of systemd-timesyncd (1/60)
[  OK  ] DietPi-Run_ntpd | NTPD: systemd-timesyncd synced
[  OK  ] NTPD: time sync | Completed
finish

- D'accord, c'est lié aux changements globaux, mais puisque tput a échoué et échoue, pourquoi nos scripts se terminent-ils maintenant et ne se sont pas arrêtés sur la v6.9?

Changement connexe identifié: https://github.com/Fourdee/DietPi/blob/master/dietpi/func/dietpi-globals#L266
local lines=$(( (${#input_string}+6)/$(tput cols) )) mène à la sortie complète du script, tandis que (précédent)

local lines
(( lines=(${#input_string}+6)/$(tput cols) ))

a montré l'erreur, mais a permis au script de continuer (voir ci-dessus).

Fix https://github.com/Fourdee/DietPi/commit/82ac7b32d32dca9db4fdb824c7ead80174844090 fonctionne et est également la solution la plus propre, car tput sera complètement ignoré dans les shells non interactifs. Mais pour éviter les pannes, nous devons revenir à la méthode précédente pour déclarer la variable d'abord, puis attribuer une valeur ensuite dans l'environnement arithmétique: Commit done https://github.com/Fourdee/DietPi/commit/0f18aa4dc0af8ab910a0173dce8849d5b53c30b0

@eljotx @kmakisara
Pour nettoyer une offre, j'ai ouvert un nouveau problème, essayez d'appliquer le correctif mentionné ici et faites un rapport, s'il résout tous les problèmes: https://github.com/Fourdee/DietPi/issues/1923

Je clôturerai ce numéro en faveur du nouveau.

Je pourrais réussir ssh dans ma v6.13 mais cela se bloquerait juste après.

La commande "tput cols" sortait tput: terminal inconnu "rxvt-256color" , résultant en une valeur vide sur la ligne 328 de dietpi-login, ce qui le bloquait pour toujours après avoir lu avec succès la base de données au démarrage initial.

L'exportation de TERM = xterm, un horrible hack, semble avoir corrigé le script de connexion et peut maintenant commencer l'installation.

Si ce n'est pas la bonne section, soyez patient, car je ne sais pas vraiment comment utiliser les problèmes de github; J'ai trouvé ce fil après des heures de recherche inutile sur Google pour une erreur, si vous le déplacez, laissez peut-être un reste sur les erreurs rxvt-256color, au cas où quelqu'un aurait le même problème.

Meilleures salutations!

@wuhei

Salut,

Merci pour le rapport et la solution 👍

Quel client SSH utilisez-vous?

@Quatre
J'ouvrais un autre numéro pour cela. Identifié le problème: https://github.com/Fourdee/DietPi/issues/2034

@wuhei
Après vous être connecté à SSH, essayez: export TERM='xterm-256color' €: Ah, c'est essentiellement ce que vous avez déjà découvert 😄.
Si cela fonctionne, vous pouvez ajouter un script à /etc/profile.d/ contenant quelque chose comme:
[[ $SSH_TTY ]] && [[ $TERM =~ 256 ]] && export TERM='xterm-256color'

• En mots: S'il s'agit d'une connexion SSH et que le client SSH a passé un terminal couleur 256 bits, ajustez-le à xterm-256color , qui est pris en charge par DietPi.

Une alternative serait d'installer un package contenant plus de définitions de terminal: G_AGI ncurses-term

@Fourdee OpenSSH_7.7p1, OpenSSL 1.1.0h sur Arch Linux

@MichaIng merci heureux d'avoir pu aider par hasard!

Gardez à l'esprit que je suis un mauvais administrateur système et en suivant cet article de Tom Ryder, j'ai découvert que j'avais une configuration de "déclaration" de terminal assez mal configurée.

En fin de compte, ce qui a résolu le problème pour moi était

• exportation du bon $ TERM dans /root/.bashrc
• copie de l'entrée terminfo correcte de mon installation arch dans le dossier /root/.terminfo de pi

Je n'ai pas pu scp le fichier terminfo sur mon pi, parce que scp n'est pas installé (peut-être envisager de l'installer avec le serveur dropbear?), Donc je l'ai téléchargé sur un serveur que je possède et je ne l'ai juste pas récupéré du pi.

Heureux d'avoir pu aider, applaudissements et encore désolé pour le désordre - Rock on!

@wuhei
Jep, définir $ TERM dans /root/.bashrc fonctionne bien sûr aussi, l'ajouter à /etc/profile[.d/] le résout à l'échelle du système pour tous les utilisateurs, ce que nous préférerions avec DietPi.

L'article que vous avez lié est plutôt sympa, expliquant très bien tout et les possibilités 👍. Vous avez donc essentiellement installé manuellement le type de terminal requis. L'article mentionne également le package ncurses-term comme option pour installer un large éventail de définitions de terminaux. Mais pour garder DietPi mince, je ne suis pas trop désireux de pré-installer ce package pour des cas aussi rares. Au lieu de cela, optez pour la solution bashrc / profile; Il est également possible de vérifier simplement la prise en charge du terminal avant d'appliquer le correctif lors de la connexion SSH.

Pour tester avec le client PuTTY: PuTTY> Connection > Data > Terminal-type string

À propos de l'installation de SCP: Il existe plusieurs autres protocoles de transfert de fichiers, FTP, SFTP ou lecteurs réseau NFS, SMB, pour transférer des fichiers. Je ne ferais pas de pré-installation, mais je laisserais le choix à l'utilisateur de savoir comment obtenir des fichiers du client au serveur. Clé USB, lecteur externe bien sûr est également possible ou simplement copier-coller dans le terminal SSH au cas où. Mais de toute façon, comme solution générale, j'irais avec l'une des deux méthodes mentionnées ci-dessus.