Incohérence commandes et backup

Support Debian
#1

Bonjour à tous,

Le DD de ma machine est ainsi organisé, sans surprise :

  • sda1 : /boot/EFI 200Mo
  • sda 2 : racine du système Debian / de 326 Go (mon home dir n’est pas dans une autre partition)
  • sda 3 : Un autre OS, 135 Go
  • sda 4 : Le SWAP du linux, 4G

Je cherche à effectuer un backup complet de mon linux, c’est-à-dire aussi bien de mes données personnelles dans mon home que du système à la racine, donc un backup de sda2. J’ai pour cela un DD externe. Ici commence les problèmes.

Le premier est anecdotique, les commandes fdisk -l et lsblk me renvoient un espace de 326 Go pour sda 2 tandis que df -hT m’informe que sda 2 fait 321 Go. J’y voie une réelle incohérence, deux réponses différentes à une “même question”, mais j’imagine que df -hT doit renvoyer volontairement des infos “simplifiés” ou quelque chose comme ça. Cela dit, j’aurai bien aimé en avoir la confirmation.

Le second est celui-ci : selon df -hT, sda2 de 321 Go est occupé par 292 Go. Pour mon backup, j’ai tout d’abord libérer sur mon DD externe un espace de 303 Go, soit 10 Go de plus que l’espace pris par l’ensemble de mon système et de mes données.

J’ai effectué le backup avec la commande suivante en me mettant à la racine :
:/# rsync -avzP * /media/toto/Backup_toto

  • a : mode archive pour conserver tout un tas de paramètre.
  • v : verbose
  • z : compression durant le transfert
  • P : partial progress en cas de coupure de la copie.

Le problème est que rsync me renvoie une erreur avant d’avoir pu tout copier : mon DD n’aurait pas suffisamment d’espace libre. J’ai fait plusieurs autres tentatives en agrandissant la partition de mon DD externe accueillant mon backup, et même avec une partition de 379 Go, soit contenant 53 Go de plus que ma partition sda 2 si elle était complète, rsync me renvoie toujours la même erreur : espace insuffisant.

Pourquoi ne puis-je pas copier 292 Go dans un espace vide de 379 Go, faute d’espace disponible ?

Je précise qu’à chaque nouvelle tentative de backup, j’ai reformaté entièrement la partition de mon DD externe avant de l’agrandir : il s’agit bien de 379 Go aussi vide que possible.

Le tout s’est déroulé de ext4 vers ext4.

Je suis un peu dérouté,

Si quelqu’un a une idée…

Merci.

#2

Je ne connais pas par coeur toutes les subtilités de rsync, mais n’y aurait-il pas une récursion infernale de /media/toto vers lui-même ?

#3

Pour df et fdisk, ils ne te renvoient pas la même information, c’est normal…
df te renoie l’espace utilisable pout des fichiers.
fdisk, lsblk, parted te donnent la taille de la partition, dans laquelle tu as tes fichiers mais aussi des informations pour dire que à tel endroit tu as tel fichier, qu’il a été modifié à telle date, qu’il porte telles permissions…
Et il pourait y avoir en plus d’autres arnaques car certains outils peuvent te mettre 1G pour 1 Gio ou pour 1 Go…

Pour tes backups, tu fais * où ? Dans / ? Si oui, ça inclut /media/toto/Backup_toto donc ça fait une belle boucle comme le dit @jweber …

#4

Oui, j’ai bien effectué le backup à la racine, et j’avoue avoir pensé à une boucle infernale aussi mais j’ai écarté cette hypothèse pour deux raisons :

  1. Il me semblerait vraiment “décevant” qu’une commande comme rsync ne gère pas par défaut un cas de figure que la simple commande cp prend en compte. Je viens d’essayer en construisant une arborescence de test avec de “faux” fichiers, et la commande cp -r (récursif) a très bien fonctionnée, me renvoyant simplement un message précisant justement qu’elle ne lancait pas cette “boucle infernale”, ne pas copiait le contenu du dossier d’arrivé dans ce dossier lui-même.

  2. Il est tout à fait possible que je me trompe, mais il me semble qu’en cas de fichiers doublons rsync supprime le doublons. Si ceci est vrai, alors la copie ne se serait certes jamais arrêté, mais l’espace prit n’aurait pas été en constante augmentation. Je vais tester ça.

Voilà ce que je peux vous dire. Bien entendu je peux me tromper, je vais continuer à chercher.

Merci @David_5.1 pour les précisions sur les commandes, je constate que c’était très logique. Je vais beaucoup moins utiliser la commande df maintenant…

Merci.

#5

Je pense que justement, dans ton cas, ce qui est pertinent, c’est ce que te donne df vu que tu copies les fichiers

Pour rsync, tu peux essayer d’ajouter --exclude=/media/toto/Backup_toto pour voir…

Pas à ma connaissance, rsync se contente il me semble de faire une copie de la source en mettant à jour si besoin les fichiers de la destination…

#6

C’est évidemment une fort sage précaution !

#7

Je vous remercie de vos réponses, mais il semble que je doive me débrouiller autrement. J’ai relancé hier soir la commande avec le nouveau paramètre :

mais je ne suis pas certain que ça ait corrigé le problème. df me renvoie à une utilisation de l’espace de ma partition backup à 100% alors que la copie n’est pas terminé, avec une taille toujours supérieure d’une cinquantaine de Go à sda2. Si elle n’est pas terminé, c’est parce que le fichier /proc/kcore nécessite entre 270 et 290 heures de transfert. Je n’arrive pas a obtenir la taille de se fichier en root avec du -h /proc/kcore (à moins qu’il ne fasse 0 octet) mais qu’importe puisque rien ne peut justifier un tel temps de transfert pour un tel fichier dans des conditions “normales”…

La seule différence avec le nouveau paramètre, c’est que la copie de mon home dir s’est faite intégralement, ce qui n’était pas encore arrivé à ma connaissance…

Peut-être qu’il est tout simplement absurde de vouloir faire un backup de sa machine de cette façon lorsque celle-ci fonctionne, même si je ne comprends pas pourquoi puisque je ne demande rien d’autre qu’une simple copie.

Dans le pire des cas, je pourrais toujours monter ma machine comme DD externe sur une autre machine et lancer la copie…

#8

rsync

tu dois donner le répertoire source ( «./» si tu es à la racine du backup, mais «/» si tu sauvegarde dés la racine système, c’ est plus sûr) (et si je fais erreur, c’est fortement recommandé)
L’avant dernier argument doit être le répertoire source (: à sauvegarder)
Le dernier argument doit être le répertoire de déstination (: la sauvegarde)

Ensuite tu crées un fichier d’ exclusion pour ne pas sauvegarder le sous-répertoire /boot, ni d’autres fichiers temporaires par exemple

Tu peux lancer rsync de n’importe-où, puisque tu donnes le répertoire source en entier ( «/» et non «./» ).

Voici la commande générée par mon script pour sauvegarder mon système et mes données dans un DD USB: (décomposé pour le commenter, à mettre évidemment en 1 seule ligne sans les commentaires)

sudo rsync -auAHXi
–stats #=> affichage d’un résumé à la fin
-vv #=> affichage très détaillé des actions (phase de débogage du script)
–log-file=/home/ADMIN/ADMIN_clevo/BKP/log/16_08_13-205737.log #=>un fichier de log
–dry-run #=> Simulation, rsync de change rien, mais montre tout ce qu’il fera)
–delete #=> efface sur la sauvegarde les fichiers effacés sur la source
–exclude-from=/usr/local/etc/exclude_rsync_clevo_sur_Toshiba.txt #=> ne sauvegarde pas ce qui y est
/ #=> Répertoire source = avant dernier argument, obligatoire
/media/laguilde/Toshiba_USB31 #=> Répertoire de sauvegarde, dernier argument, obligatoire

Le man est très complet, y compris la syntaxe des expressions génériques (*, **)

Pour savoir qu’exclure, on en a déja discuté ici: (et on peut continuer)
https://forum.debian-fr.org/t/sauvegarde-rsync-que-mettre-dans-exclude-from/67718

À noter également le sudo qui n’est sans doute pas nécessaire pour un répertoire /home si tu es le seul utilisateur. Sinon, penser à mettre rsync dans sudo.

#9

Ajoute --exclude=/dev --exclude=/proc --exclude=/run --exclude=/sys --exclude=/tmp --exclude=/var/tmp c’est des trucs qui sont créés automatiquement au démarrage ou qui contiennent des fichiers temporaires et qu’il est donc inutile de sauvegarder.

man file-hierarchy si tu veux plus d’infos :slight_smile:

Le problème que tu as avec /proc, c’est qu’il y a dedans des fichiers qui n’ont pas de taille parce que ce ne sont pas des fichiers mais que tu peux lire et qui peuvent te renvoyer beaucoup de données… Chez moi, kcore est annoncé comme faisant 128Tio…