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

Posté par . Licence CC by-sa
4
27
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 . É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 . Évalué à 2. Dernière modification le 27/12/12 à 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 . É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 . É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 . Évalué à 0. Dernière modification le 27/12/12 à 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 . É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 . É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 . Évalué à 1.

      Je suis pas sûr pour ton calcul.

      128 Go (Gio bien évidemment…)

      128*10243
      137438953472

      10 Mo = 10*10242

      137438953472/(10*10242)
      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 . É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 . É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 . Évalué à 1. Dernière modification le 27/12/12 à 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 . É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 . É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 . É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 . Évalué à 0. Dernière modification le 28/12/12 à 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 . É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 . Évalué à 0. Dernière modification le 29/12/12 à 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 . É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 . É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 . É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 . É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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.