Forum Linux.général Sauvegarde d'un SDD dans un fichier ?

Posté par PolePosition le 27 décembre 2012 à 22:26. Licence CC By‑SA.

Étiquettes :

déc.

2012

Hi,

Dîtes-moi, s'il vous plaît, est-il possible dans faire une sauvegarde d'un SSD (y compris la table des partitions, le MBR, etc), via la commande :

dd bs=10M count=200G if=/dev/sda of=/DATAS_RAID1/backup_sda.bkp

/dev/sda étant le SSD de 128 Go
/DATAS_RAID1/backup_sda.bkp étant l'endroit où je veux stocker la backup

Actuellement, je fais ça, sauf que la destination est un disque. J'utilise donc un disque de 1 To pour sauvegarder un SSD de 128 Go, c'est moyen…..

En cas de problème, je n'aurai donc qu'à faire :

dd bs=10M count=200G if=/DATAS_RAID1/backup_sda.bkp of=/dev/sda

Correct ?

# Yep !

Posté par Zylabon le 27 décembre 2012 à 22:49. Évalué à 6.

Tout est fichier.

Le paramètre count est tout à fait optionnel, s'il n'y est pas dd s'arrête simplement à la fin du fichier.

Sinon, les images disques ça se compresse très bien.

dd if=/dev/disque | machin_de_compression > /DATA/disque.backup
machin_de_decompression_cat /DATA/disque.backup | dd of=/dev/disque

Please do not feed the trolls
# Bizarre

Posté par Marotte ⛧ le 27 décembre 2012 à 22:55. Évalué à 2. Dernière modification le 27 décembre 2012 à 22:58.

Je comprends pas pourquoi tu fais count=200G. C'est une syntaxe que je ne connais pas et en plus ton SSD fait 128 Go.

À ma connaissance on écrit count=N (N est un entier qui n'a pas d'unité), la taille du fichier écrit étant égale à BS (blocksize) * N

Selon moi tu n'as pas besoin de count, dd s'arrêtera quand il n'y aura plus rien à lire…

D'autre part, pourquoi avoir choisi 10M comme taille de bloc ?

En faisant :

dd if=/dev/sda of=fichier

Tu aura un fichier de la taille de ton device. Pour « restaurer » :

dd if=fichier of=/dev/sda

J'ai peut-être mal compris ton problème…

EDIT :

À la lecture du man de dd :

BLOCS et OCTETS peuvent être suivis de l'un des suffixes multiplicatifs suivants : c = 1, w = 2, b = 512,
kB = 1000, K = 1024, MB = 1000*1000, M = 1024*1024, xM = M, GB = 1000*1000*1000, G = 1024*1024*1024 et ainsi de
suite pour T, P, E, Z, Y.

Donc là tu essayes de faire une copie de 10M * 200G ce qui est largement plus de 128 Go…
- [^] # Re: Bizarre
  
  Posté par PolePosition le 27 décembre 2012 à 23:00. Évalué à -1.
  
  Hi,
  
  Si si vous avez tous les deux compris.
  Effectivement count est parfaitment inutile.
  Et pour ce qui est de bs, j'avais lu qu'on peut essayer avec différentes valeurs, pour optimiser en fonction du système (bande-passante, etc.). Mais n'en suis pas ŝur.
  
  Je n'aurai jamais osé compresser. Mais bon, tant que c'est non destructeur, c'est vrai que ça ne doit pas poser de problème.
  
  Je vais donc tenter de trouver un bon algo : LZMA, BZIP ou je ne sais pas trop quoi.
  
  Merci !
  
  PS : prochaine étape, les snapshots LVM !! Que du bon !! C'est mon festin de repas de noël-nouvel-an.
  - [^] # Re: Bizarre
    
    Posté par Marotte ⛧ le 27 décembre 2012 à 23:14. Évalué à 1.
    
    Je ne m'explique toujours pas ça :
    
    Actuellement, je fais ça, sauf que la destination est un disque. J'utilise donc un disque de 1 To pour sauvegarder un SSD de 128 Go, c'est moyen…..
    
    Avec ta commande il me semble que effectivement le count ne sert à rien mais la commande devrait quand même se terminer à la fin de /dev/sda
    
    Autrement dit le fichier /DATAS_RAID1/backup_sda.bkp devrait faire exactement la taille du SSD, soit 128 Go
    
    Ou bien alors actuellement tu fais dd if=/dev/sda of=/dev/sdb où sda est ton SSD et sdb ton disque de 1 To ? Dans ce cas oui c'est un peu con ;) Tu pourrais éventuellement quand même utiliser le reste du disque avec dd en jouant avec le paramètre offset mais là ce serait très casse gueule !
    - [^] # Re: Bizarre
      
      Posté par PolePosition le 27 décembre 2012 à 23:25. Évalué à 0. Dernière modification le 27 décembre 2012 à 23:27.
      
      Re,
      
      En fait je pensais qu'il fallait dire à dd jusque où il faut copier. Je savais très bien qu'il s'arrêterai au bout des 128 Go.
      Mais je ne savais pas qu'il était possible de ne pas du tout lui indiquer la limite. Voilà…
      Donc maintenant je n'utiliserai plus ce paramètre, car parfaitement inutile dans mon cas.
      
      Effectivement, j'avais pensé à l'offset pour faire le backup d'un autre SSD, mais je ne me sens pas assez joueur pour le faire.
      
      Je vais appliquer ce que vous m'avez dit asap pour faire un bkp dans un fichier (avec compression ON THE FLY :-)
      
      +
  - [^] # Re: Bizarre
    
    Posté par Zylabon le 27 décembre 2012 à 23:29. Évalué à 3.
    Pour t'assurer que les copies sont bien faite tu peux comparer les hash, par exemple comparer dd if=/dev/disque | sha256sum à zcat disque.bakup | sha256sum
    
    pour le bs, je lis que par défaut sur mon implémentation c'est 512 octets, effectivement c'est peu. ça fait beaucoup d'appel système pour rien (dd va lire 512 octets sur l'entrée en les copiant dans sa mémoire, puis les écrire sur la sortie, et recommencer). Plus la valeur de bs est élevée, plus dd consommera de mémoire, et moins il aura à faire d'appels systèmes. Il faut qu'il soit assez gros pour que le temps des appels systèmes soient négligeable à coté du temps passé à lire le disque. Avec 10M t'es tranquille, avec 1k les performances seraient pas très différentes.
    
    Petit bench juste pour vous sur mon ordi portable, avec un disque dur traditionnel :
```
[root@computer ~]# dd if=/dev/sda bs=20M count=512 of=/dev/null
10737418240 octets (11 GB) copiés, 159,839 s, 67,2 MB/s

[root@computer ~]# dd if=/dev/sda bs=10M count=1k of=/dev/null
10737418240 octets (11 GB) copiés, 161,818 s, 66,4 MB/s

[root@computer ~]# dd if=/dev/sda bs=1k count=10M of=/dev/null
10737418240 octets (11 GB) copiés, 160,273 s, 67,0 MB/s

[root@computer ~]# dd if=/dev/sda bs=512 count=20M of=/dev/null
10737418240 octets (11 GB) copiés, 160,163 s, 67,0 MB/s
```
    Conclusion : bonnet blanc et blanc bonnet
    
    Please do not feed the trolls
# oui mais attention aux multiplications

Posté par NeoX le 27 décembre 2012 à 22:57. Évalué à 2.

bs=10M avec count 200G
ca va te faire quelques To

si je ne m'abuse
128Go par tranche de 10Mo ca n'en fait qu'un count=12800
- [^] # Re: oui mais attention aux multiplications
  
  Posté par Marotte ⛧ le 27 décembre 2012 à 23:05. Évalué à 1.
  
  Je suis pas sûr pour ton calcul.
  
  128 Go (Gio bien évidemment…)
  
  128*1024³
  137438953472
  
  10 Mo = 10*1024²
  
  137438953472/(10*1024²⁾
  13107.20000000000000000000
  
  Du coup je pense que c'est même pas possible de tomber juste avec des blocs de 10M
  
  En espérant ne pas faire d'erreur non plus ! :)
  - [^] # Re: oui mais attention aux multiplications
    
    Posté par NeoX le 27 décembre 2012 à 23:22. Évalué à 3.
    
    oui Marotte tu as raison j'ai pas fait la precision sur 1024 et ses multiples
    c'etait surtout pour attirer l'attention sur la multiplication BSxCount
# c'est quand meme tres bourrin

Posté par NeoX le 27 décembre 2012 à 23:34. Évalué à 4.

prenons le cas ou tu as un disque de 128Go
tu installes linux dessus, ca occupe 8go
quelques videos/music pour 20Go

ca occupe donc en tout 28Go
et tu vas faire un backup qui va faire 128Go pour 28Go de données utiles.

y a surement des methodes plus efficaces.

on peut commencer par une simple
ca peut etre une simple synchro de dossiers avec rsync et les bonnes options pour synchroniser :
- tout le /
- sauf /media/disque1To
- dans le /media/disque1To/backupSSD128Go/

pour restaurer il n'y a alors plus qu'a
- demarrer sur un liveCD,
- monter les deux disques
- syncrhroniser depuis le backup vers le SSD
- chrooter le SSD pour reinstaller grub
- redemarrer
- [^] # Re: c'est quand meme tres bourrin
  
  Posté par PolePosition le 27 décembre 2012 à 23:47. Évalué à 1. Dernière modification le 27 décembre 2012 à 23:50.
  
  Salut,
  
  C'est justement parce que j'ai peur de GRUB que je fais ça.
  Maintenant je suis peut être un master du RAID, grace à toi, tout à l'heure :) mais GRUB me fout un peu la trouille.
  J'ai pas mal d'appli compilonée-installées-configurées aux petits oignons et je ne voudrais pas être bloqué à cause de GRUB !
  
  PS : je fais déjà du rsync, mais pour des backups de DATAS sur des disques externes (deux disques, au cas ou l'un des deux viendrait à lacher)
  
  PS : et effectivement, sur mon SSD root il n'y a que 16 Go d'utilisé ! Ce n'est pas très efficace comme ratio !
  
  +
  - [^] # Re: c'est quand meme tres bourrin
    
    Posté par NeoX le 27 décembre 2012 à 23:50. Évalué à 3.
    
    une idée en passant si ta machine est recente, avec plus de 2Go de ram et vu que tu as un disque de 1To
    installes virtualbox et entraine toi dans des machines virtuelles.
    
    reinstaller un grub à partir d'un chroot precedemment sauvegardé, c'est 5 à 7 lignes de commandes en tout à connaitre
    - [^] # Re: c'est quand meme tres bourrin
      
      Posté par PolePosition le 27 décembre 2012 à 23:53. Évalué à 0.
      
      J'utilise Virtualbox :)
      Bon et bien je vais me pencher dessus alors.
      J'ai déjà chrooté pour installer GRUB (lors de l'installation de Arch).
      Lors de cette install, j'avais galéré pour le chiffrement de la partition / et les hooks à déclarer
      
      Il va falloir que je me retrousse les manches pendant une heure et je prendrai les notes qu'il faut.
      
      Merci encore !
  - [^] # Re: c'est quand meme tres bourrin
    
    Posté par detail_pratique le 27 décembre 2012 à 23:57. Évalué à 1.
    
    Et sinon, en un peu moins (encore que) pédagogique mais diablement efficace : Mondorescue
    
    «
    Mondo Rescue is a GPL disaster recovery solution. It supports Linux (i386, x86_64, ia64) and FreeBSD (i386). It's packaged for multiple distributions (Fedora, RHEL, openSuSE, SLES, Mandriva, Mageia, Debian, Ubuntu, Gentoo).
    It supports tapes, disks, network and CD/DVD as backup media, multiple filesystems, LVM, software and hardware Raid.
    
    You need it to be safe.
    »
    - [^] # Re: c'est quand meme tres bourrin
      
      Posté par PolePosition le 28 décembre 2012 à 00:01. Évalué à 0. Dernière modification le 28 décembre 2012 à 00:02.
      
      Salut detail_pratique,
      
      J'ai déjà testé.
      Je n'aime pas ces outils : je trouve ça inutilement lourd. Je préfère galérer les premières fois, puis me faire mon petit HOWTO perso et roulez.
      
      Le pire soft de backup qui existe dans l'Univers, c'est celui de Norton. Un vrai clickodrome.
      Tu as l'impression de ne rien "sentir", de ne rien contrôler. Moi je dis, vive les bisous (KISS).
      
      Je vais faire comme Neox le suggère, c'est efficace et a un côté pédagogique !
      - [^] # Re: c'est quand meme tres bourrin
        
        Posté par detail_pratique le 28 décembre 2012 à 00:36. Évalué à 1.
        
        Mondo est tout-à-fait KISS(able).
        
        Il n'est pas lourd et n'a vraiment rien à voir avec Norton.
        Et je ne connais pas de petit howto perso qui permette de reprendre une machine de zéro avec 1 seule manip (démarrer avec le disque qui contient l'archive),et qui permette en même temps de reformater automatiquement (/ fixe à 1 Gio, swap fixe à 4, /usr à 30, et le reste pour /home) en cas de changement de disque dur.
        
        Bref. Bonnes vacances :)
        
        [^] # Re: c'est quand meme tres bourrin
        
        Posté par PolePosition le 29 décembre 2012 à 22:29. Évalué à 0. Dernière modification le 29 décembre 2012 à 22:30.
        
        Hello,
        
        Ok donc va pour le rsync !
        J'en fais souvent pour des données, mais là, je suis un peu inquiet, car il faut préserver les droits exacts des fichiers, les permissions exactes, copier les fichiers cachés.
        Car il ne s'agit plus de data mais de fichiers binaires, de bibliothèques, etc !
        
        Est-ce que les commandes suivantes peuvent convenir ?
        
        rsync --progress --verbose --delete --checksum --recursive $MASTER/courses/ $SLAVE/courses/
        rsync --progress --verbose --delete --checksum --recursive $MASTER/documents/ $SLAVE/documents/
        rsync --progress --verbose --delete --checksum --recursive $MASTER/projects/ $SLAVE/projects/
        
        D'après Google, je pense qu'avec ces commandes les hidden files seront copiés, mais quid des permissions exactes ?
        
        +
        
        [^] # Re: c'est quand meme tres bourrin
        
        Posté par NeoX le 29 décembre 2012 à 23:33. Évalué à 2.
        
        perso j'utiliserais simplement :
        
        rsync -aP --delete $SOURCE $DEST
        
        -a pour archive qui est raccourci de plusieurs options dont le recursif
        -P pour progress
        --delete que tu connais deja
        
        [^] # Re: c'est quand meme tres bourrin
        
        Posté par PolePosition le 30 décembre 2012 à 11:25. Évalué à 1.
        
        Hello,
        
        J'ai trouvé une page géniale :
        
        https://wiki.archlinux.org/index.php/Full_System_Backup_with_rsync
        
        Elle correspond au besoin !
        
        J'ai exclu /opt (Matlab….. etc) ainsi que .firefox .thunderbird etc.
        Je me retrouve avec un répertoire BKP_ISO de 5.8 GB.
        C'est infiniment plus efficace que le dd !
        
        Maintenant, je voudrais en faire une archive, mais ai peur de modifier les droits des fichiers, les bits spéciaux, etc.
        Puis-je me contenter de faire un tar cf BKP_ISO.tar BKP_ISO/* ?
        
        Ensuite je voudrais le compresser (voire même à la volée) ?
        Qu'est-ce que vous conseillez entre bzip, gzip, lzma ?
        
        +
        
        [^] # Re: c'est quand meme tres bourrin
        
        Posté par NeoX le 30 décembre 2012 à 12:13. Évalué à 3.
        
        tu peux tres bien en faire une archive avec tar et meme compresser à la volée.
        
        tar dispose des options
        -z pour compresser avec gzip, ce qui te donne les archives qu'on nomme tar.gz ou tgz et que tu as pu croisées.
        -j pour compresser avec bzip ou bzip2
        
        et y en a surement d'autres.
        
        à noter que le premier rsync va envoyer toutes les données
        le suivant ne va envoyer que ce qui a changé pour synchroniser ton dossier de backup.
        
        mais tu pourrais aussi tres bien faire directement le tar des dossiers à backuper sans passer par l'etape rsync.
        rsync n'etant là que pour isoler les fichiers avant sauvegarde dans le tar
        
        [^] # Re: c'est quand meme tres bourrin
        
        Posté par PolePosition le 30 décembre 2012 à 13:53. Évalué à 0.
        
        1,9 GB versus 128 GB !
        
        [bastien@zoulou ~]$ ls -lh BKP_OS.tar.bzip2
        -rw-r--r-- 1 root root 1.9G Dec 30 12:42 BKP_OS.tar.bzip2
        [bastien@zoulou ~]$
        
        En cas de soucis je n'aurai qu'à faire un truc du genre (je tenterai pour affiner les commandes nécessaires et les noterai) :
        
        arch-chroot /mnt
        grub-install /dev/sda
        
        Parfait !!!!!!
        Merci beaucoup !
        
        [^] # Re: c'est quand meme tres bourrin
        
        Posté par Zylabon le 30 décembre 2012 à 14:44. Évalué à 4.
        
        tar dispose des options
        -z pour compresser avec gzip, ce qui te donne les archives qu'on nomme tar.gz ou tgz et que tu as pu croisées.
        -j pour compresser avec bzip ou bzip2
        
        et y en a surement d'autres.
        
        -a pour détecter automatiquement la compression à appliquer en fonction du nom de l'archive, archive.tar.xz sera compressée avec xz, archive.tar.gz sera compressé avec gzip…
        
        Please do not feed the trolls
        
        [^] # Re: c'est quand meme tres bourrin
        
        Posté par PolePosition le 30 décembre 2012 à 17:59. Évalué à 0.
        
        Hi,
        
        Ouais, j'essaie de toujours utiliser les notations longues, pour les retenir plus facilement :
        
        tar --bzip2 --create /home/bastien/BKP_OS/ --file /home/bastien/BKP_OS.tar.bzip2
        
        Je vais effectivement modifier le nom en tar.bz2
        
        Je pense laisser le niveau de compression par défaut, car il est vraiment efficace et un ratio plus agressif rendrait les choses plus longues.
        J'ai hésité entre bzip et lzma mais bzip est plus souvnet intégré aux LiveCD. Peut être que lzma l'est également, mais vu le résultat très satisfaisant que j'ai déjà avec bzip, je ne veux pas passer de temps à checker plusieurs liveCD….. juste pour voir si lzma est intégré…
        
        Merci des conseils.
        
        +

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.