[reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

rmy · Le 07/10/2010, à 19:57

côté uuid ça a l'air OK. Je n'ai rien tenté pour le moment, parce qu'il y a des détails qui m'échappent, et j'aimer comprendre ce que je fais. Surtout quand ça concerne la récup de données, tu t'en doute

Par ailleurs je vois dans ce backup (enfin je suppose, je lis assez mal le backup ancien dans le texte) que les lv étaient sur pv1, et moi c'est ceux qui sont (seraient) sur pv0 qui m'intéressent… et-ce donc utile de restaurer ce backup…?

chopinhauer · Le 07/10/2010, à 20:11

Bah, c'est un backup assez récent et, comme tu vois, toutes les LV sont sur le PV 'pv1' (/dev/mapper/cryptroot). Peut-être t'as plus de chance dans /etc/lvm/archive.

Sinon tu peux sortir le RAID du VG debian, puis copier ce fichier et le modifier pour ce qu'on pense était l'allocation de volumes sur le RAID. C'est à dire:

* Surement modifier le nom et le UUID du VG (inverser deux lettres suffit :-) ).
* Enlever l'entrée du 'pv1' (cryptroot)
* Modifier les entrées des LV pour dire que c'est 'pv0', pas 'pv1' leur périphérique.

Après un:

vgcfgrestore -f <le_fichier_modifié>

devrait faire apparaître un nouveau VG, avec les bons LV.

Dernière modification par chopinhauer (Le 07/10/2010, à 20:12)

rmy · Le 07/10/2010, à 20:14

Je savais pas qu'on pouvait faire de la cuisine comme ça avec les lvm !!
Bon, je regarde dans archive et je repasse.

Edit : celui-ci me paraît être le plus intéressant, c'est celui jsute avant le pvmove vers le raid lors du premier pvmove de ma tentative de migration.

sudo cat /etc/lvm/archive/debian_00007.vg
# Generated by LVM2 version 2.02.54(1) (2009-10-26): Tue Sep 21 10:49:13 2010

contents = "Text Format Volume Group"
version = 1

description = "Created *before* executing 'pvmove /dev/mapper/cryptroot -i 5'"

creation_host = "rmyprod"    # Linux rmyprod 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686
creation_time = 1285058953    # Tue Sep 21 10:49:13 2010

debian {
    id = "CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgUe"
    seqno = 12
    status = ["RESIZEABLE", "READ", "WRITE"]
    flags = []
    extent_size = 8192        # 4 Megabytes
    max_lv = 0
    max_pv = 0

    physical_volumes {

        pv0 {
            id = "TJdpFD-iTRr-jQxg-jqqk-5gPU-tHwL-T28IUV"
            device = "/dev/mapper/cryptroot"    # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 1249758554    # 595,931 Gigabytes
            pe_start = 384
            pe_count = 152558    # 595,93 Gigabytes
        }

        pv1 {
            id = "NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg"
            device = "/dev/md0p1"    # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 3907024002    # 1,81935 Terabytes
            pe_start = 577
            pe_count = 476931    # 1,81935 Terabytes
        }
    }

    logical_volumes {

        swap_1 {
            id = "LxEGT1-fmgR-XGGX-byOt-j2p6-bXrs-SasLSs"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 648    # 2,53125 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 1668
                ]
            }
        }

        rootbuntu {
            id = "qjJsVW-8iWp-CT0H-YqoS-hsl1-yFTL-MlzMub"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 3840    # 15 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 53772
                ]
            }
        }

        homebuntu {
            id = "fo3HBW-BL0n-ctuO-Rgg7-U03h-Vorb-bjq8cP"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 3

            segment1 {
                start_extent = 0
                extent_count = 94946    # 370,883 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 57612
                ]
            }
            segment2 {
                start_extent = 94946
                extent_count = 51456    # 201 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 2316
                ]
            }
            segment3 {
                start_extent = 146402
                extent_count = 1668    # 6,51562 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 0
                ]
            }
        }
    }
}

Là, les LV sont sur pv0, mais pv0 c'est cryptroot. L'idée de restaurer tel quel en modifiant pv0/pv1 uniquement ne me plait guère, parce que du coup si ça foire, je remets probablement mon lvm cryptroot dans le sac. Je serai plus tenté effectivement d'essayer de modif les ID et de sortir le raid du VG. Je vais essayer de le faire, mais pour chaque étape, j'attendrai ta confirmation, si tu veux bien. Comme ça, je comprendrai mieux comment ça marche.

Dernière modification par rmy (Le 07/10/2010, à 20:26)

rmy · Le 07/10/2010, à 20:28

Donc là, je commence par un

sudo vgreduce debian /dev/md0p1

exact ?

chopinhauer · Le 07/10/2010, à 20:36

Oui, commence par un vgreduce. Par contre tu n'as pas de configuration après la migration? Car par exemple là homebuntu est en trois morceaux. Je suis quasiment certains que pvmove l'a remis dans un seul morceau lors de la migration.

Je dirais de modifier quand même le premier fichier que t'as posté. Au pire tu peux réessayer avec celui-ci après.

rmy · Le 07/10/2010, à 20:46

Oui je viens de voir ça… j'étais déjà en train de modifier le fichier en question. Pendant que je reprends l'autre, saurais tu m'expliquer ce que c'est que

seqno = 12

dans la déclaration du vg, pour savoir si je dois le modifier…

rmy · Le 07/10/2010, à 20:52

donc la suite serait :
je me crée un faux_backup.vg :

# Generated by rmy : Oct 07 20:33:30 2010 cuisine de backup sur md0p1

contents = "Text Format Volume Group"
version = 1

description = "Created before data recovery on /dev/md0p1"

creation_host = "rmyprod"    # Linux rmyprod 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686
creation_time = 1286476754    # jeudi 7 octobre 2010, 20:39:14 (UTC+0200)

devian {
    id = "CryiJf-tvAL-2yZK-rj1I-R5Im-HrTM-OwCgeU"
    seqno = 12
    status = ["RESIZEABLE", "READ", "WRITE"]
    flags = []
    extent_size = 8192        # 4 Megabytes
    max_lv = 0
    max_pv = 0

    physical_volumes {
      
        pv0 {
            id = "NT2mUJ-71Zq-iH2V-wX21-3CkG-lvLN-6gvmQg"
            device = "/dev/md0p1"    # Hint only

            status = ["ALLOCATABLE"]
            flags = []
            dev_size = 3907024002    # 1,81935 Terabytes
            pe_start = 577
            pe_count = 476931    # 1,81935 Terabytes
        }
    }

    logical_volumes {

        swap_2 {
            id = "LxEGT1-fmgR-XGGX-byOt-j2p6-bXrs-SasLsS"
             status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 648    # 2.53125 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 0
                ]
            }
        }

        bisrootbuntu {
            id = "qjJsVW-8iWp-CT0H-YqoS-hsl1-yFTL-MlzMbu"
            status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 3840    # 15 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 648
                ]
            }
        }

        bishomebuntu {
            id = "fo3HBW-BL0n-ctuO-Rgg7-U03h-Vorb-bjq8Pc"
             status = ["READ", "WRITE", "VISIBLE"]
            flags = []
            segment_count = 1

            segment1 {
                start_extent = 0
                extent_count = 148070    # 578.398 Gigabytes

                type = "striped"
                stripe_count = 1    # linear

                stripes = [
                    "pv0", 4488
                ]
            }
        }
    }
}

où j'ai modifié le nom du VG, l'ID du vg, les noms des LV, et leurs IDs.

Dernière modification par rmy (Le 07/10/2010, à 20:56)

chopinhauer · Le 07/10/2010, à 21:05

seqno ça doit être le numéro de version des métadonnées de ce VG en particulier, donc sans importance.

T'es sur d'avoir modifié le ID du VG? Il me semble le même.

Sauf ça à mon avis tu peux le charger avec 'vgcfgrestore -f <fichier>' et voire si c'était le bonne données.

rmy · Le 07/10/2010, à 21:30

Ouaip j'ai inversé les deux dernières lettres

rmy · Le 07/10/2010, à 21:33

sudo vgcfgrestore devian -f faux_backup.vg 
  Restored volume group devian

rmy · Le 07/10/2010, à 21:40

Montage fonctionnel. Merci pour toutes ces infos précieuses. Je ne sais pas où j'ai merdé dans l'analyse, mais les données de la frangine n'y sont pas

Bon, vu que ça, c'est fait, on va pouvoir passer à autre chose…

Par contre, vu l'état de mon cerveau, je vais reprendre ça tranquillement demain…

Dernière modification par rmy (Le 07/10/2010, à 21:57)

rmy · Le 09/10/2010, à 10:42

Hop, je me remets à l'ouvrage:
1ère étape, tester la solution initialement prévue avant de tout (encore) re-casser pour remettre les choses à plat.

Donc cette nuit, pendant la migration du forum, j'ai fait:

sudo lvremove /dev/mapper/devian-* -v
sudo vgremove devian
   sudo pvremove /dev/md0p1 -v

puis

sudo mdadm --manage /dev/md0 --fail /dev/sd[b|c|d]1

(un par un)
et

sudo mdadm --manage --stop /dev/md0

ensuite j'ai repartitionné mes disques (j'ai oublié au passage de laisser plus de place pour grub, mais vu que ce n'est qu'une situation provisoire pour tests, je ne vais pas recommencer le sync complet ^^)
>> Question au passage: pour réduire un volume raid (ici, /dev/md1, en laissant plus de place "devant", il aurait vraiment fallu démonter le raid, réduire chaque partition, et le reconstruire ou bien il y a plus court comme manip?

Puis je me suis refait deux volumes raid: md1 en raid1 sur sdb1,sdc1 (avec prévision d'extension pour le test à raid 1+0 après) et md0 en raid5 sur sdb2,sdc2,sdd2…

sudo mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sd[bcd]2
mdadm: array /dev/md0 started.

 sudo mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sd[bc]1
mdadm: array /dev/md1 started.

sudo mdadm --daemonise /dev/md0
sudo mdadm --daemonise /dev/md1

sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Sat Oct  9 03:58:19 2010
     Raid Level : raid5
     Array Size : 1952989696 (1862.52 GiB 1999.86 GB)
  Used Dev Size : 976494848 (931.26 GiB 999.93 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Oct  9 07:00:57 2010
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 6ac8eba5:c657b0f7:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.42

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8       34        1      active sync   /dev/sdc2
       2       8       50        2      active sync   /dev/sdd2

sudo mdadm --detail /dev/md1
/dev/md1:
        Version : 00.90
  Creation Time : Sat Oct  9 03:58:56 2010
     Raid Level : raid1
     Array Size : 264960 (258.79 MiB 271.32 MB)
  Used Dev Size : 264960 (258.79 MiB 271.32 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Sat Oct  9 07:01:02 2010
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : ce2da1a5:85ce2b96:38068b2c:eb3ab5c6 (local to host rmyprod)
         Events : 0.37

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       33        1      active sync   /dev/sdc1

Voilà. À suivre ci-dessous.

rmy · Le 09/10/2010, à 10:57

Donc ensuite je crée mon conteneur luks:

sudo cryptsetup luksFormat -c aes -h sha256 /dev/md0
sudo cryptsetup luksOpen /dev/md0 cryptraid

Puis voici la check-list de ce qui va venir après: Arrêtez-moi si il y a galère à prévoir…

ma note de cette nuit a écrit :

vgcfgbackup
puis lvm à migrer
/boot à créer sur md1 + rsync
crypttab à changer
fstab à modifier
grub à réinstaller
rebooter

sudo vgcfgbackup debian -f backup_lvm_debian_avant_migration_20101008.vg
  Volume group "debian" successfully backed up.

copie du fichier sur support externe…

Et c'est parti pour le nouveau lvm:

sudo pvcreate /dev/mapper/cryptraid 
  Physical volume "/dev/mapper/cryptraid" successfully created

sudo vgextend debian /dev/mapper/cryptraid
  Volume group "debian" successfully extended

Puis enfin

sudo pvmove /dev/mapper/cryptroot /dev/mapper/cryptraid -i 5

À suivre… prochain épisode après la fin de la migration

Bon, en attendant, comme ça prend du temps, j'ai finalement déconstruit mon md1, pour faire de la place avant les partitions sd[bcd]1 et remonter plutôt le raid1 sur sd[cd]1 pour pas m'y perdre après…

Et je continue ma checklist:

sudo mount /dev/md1 /mnt
sudo rsync /boot/ /mnt/ -a --stats --progress --filter "- lost+found"

en passant ( /dev/mapper/cryptroot: Moved: 33,4%)

Je modifie donc crypttab
ancien:

cat /etc/crypttab
# <target name>    <source device>        <key file>    <options>
cryptroot        /dev/sda2    none    luks,retry=1,lvm=debian

nouveau:

cat /etc/crypttab
# <target name>    <source device>        <key file>    <options>
cryptraid        /dev/md0    none    luks,retry=1,lvm=debian

Dernière modification par rmy (Le 09/10/2010, à 13:52)

rmy · Le 09/10/2010, à 14:01

pour le fstab, pour l'instant je n'ai modifié que la ligne du /boot, je ne sais pas si les lv changent d'uuid lors du pvmove. Je ne pense pas, mais je vérifierai quand même avant le reboot.

cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
#/dev/mapper/debian-rootbuntu
UUID=4682429c-6781-4ed4-8a3d-44682d0144c9 /               ext3    relatime,errors=remount-ro 0       1
# /dev/md1
UUID=542382d5-d743-4b1c-a09f-bc5130fb9495 /boot           ext4    relatime        0       2
# /dev/mapper/debian-homebuntu
UUID=790c47bd-0706-425a-b42d-e3cef41cfd72 /home           ext3    relatime        0       2
# /dev/mapper/debian-swap_1
UUID=10424d7d-071f-4d72-8fd5-3425c17615f5 none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0

rmy · Le 09/10/2010, à 14:06

Voilà, j'ai plus qu'à attendre.

Il me reste à:
sortir cryptroot du vg,
réinstaler grub correctement
vérifier si il ne faut rien de plus (faut pas rajouter qq chose à initramfs?)
edit: modifier mdadm.conf, il n'y a pas de trace de /dev/md1 actuellement
éteindre,
enlever sda
rebooter.

Le pvmove va durer un moment encore… chopinauer, Hoper, si vous passez par là et que le blanc ne vous brûle pas trop les yeux, n'hésitez pas à donner votre avis sur les manips…

Dernière modification par rmy (Le 09/10/2010, à 14:56)

chopinhauer · Le 09/10/2010, à 15:39

À ajouter à la checklist:
* Donner le paramètre '--modules' à grub-install, la liste devrait contenir 'mdraid' et 'ext2' (même si grub-install va probablement se charger de ce dernier). La liste des modules disponibles est dans /usr/lib/grub. T'as aussi un module 'crypto' si tu veux t'amuser.
* update-initramfs pour copier le mdadm.conf dans le initrd.

Dernière modification par chopinhauer (Le 09/10/2010, à 15:40)

rmy · Le 09/10/2010, à 17:09

merci

Mais, ce module crypto, ça veut dire qu'il est bel est bien possible de mettre tout (j'ai compris, hein, je ne le ferai pas), même /boot, dans un lvm chiffré, non?

(/dev/mapper/cryptroot: Moved: 79,7%)

chopinhauer · Le 09/10/2010, à 17:22

Je pense que oui. Si tu regardes Grub a plein de modules cryptographiques pour n'importe quel algorithme. Ce n'est pas documenté par contre, donc il faudrait regarder dans les sources comme s'en servir.

rmy · Le 09/10/2010, à 19:13

une autre fois… mais le sujet m'intéresse…

rmy · Le 10/10/2010, à 09:15

  /dev/mapper/cryptroot: Moved: 100,0%

Vais-je réussir à rebooter le 10.10.10 ? Plus tard, peut-être…

rmy · Le 10/10/2010, à 18:49

Bon, me revlà.

Alors déjà, un doute m'assaille: j'ai du merdouiller lorsque j'ai reconstruit mon raid1, parce que là en voulaut mettre à jour mon mdadm.conf, j'ai ça:

sudo mdadm --examine --scan 
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=ce2da1a5:85ce2b96:38068b2c:eb3ab5c6
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=a8faec27:afb2d420:38068b2c:eb3ab5c6
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=6ac8eba5:c657b0f7:38068b2c:eb3ab5c6

Bon, comme

ls -l /dev/disk/by-uuid

me donne:

uuid md1 a écrit :

542382d5-d743-4b1c-a09f-bc5130fb9495 -> ../../md1

Je me dit qu'il y a vraiment un cafard dans le potage…

En plus gparted me marque un /dev/md1p1 alors qu'il n'y en a pas, mais la repère en ext4 quand même… oO

Ça me semble pas net cette histoire…

sudo blkid
/dev/md1: UUID="542382d5-d743-4b1c-a09f-bc5130fb9495" TYPE="ext4"

Que faire…

chopinhauer · Le 10/10/2010, à 19:38

Les UUID du RAID ne sont pas les même que ceux de blkid. Ce dernier donne le UUID des systèmes de fichiers, qui sont sur le RAID.

Effectivement t'as deux RAID 1, chacun avec deux disques et un total de 3 disques. :-)

Dans le message #112 t'as ajouté uniquement sdb1 et sdc1 au RAID 1: c'est 'ce2da1a5:85ce2b96:38068b2c:eb3ab5c6'. La partition sda1 a encore le super-bloc d'un des RAID passées. Donne lui un coup de 'mdadm --zero-superblock' et refait le 'mdadm --examine --scan'.

Dernière modification par chopinhauer (Le 10/10/2010, à 19:38)

rmy · Le 10/10/2010, à 21:01

Ok, merci. En fait, c'est pas /dev/sda1, c'est /dev/sdb1 que j'avais oublié. Mais du coup j'ai compris mon erreur.

sudo mdadm --examine --scan
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=a8faec27:afb2d420:38068b2c:eb3ab5c6
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=6ac8eba5:c657b0f7:38068b2c:eb3ab5c6

c'est plus clair.

et merci aussi pour la précision concernant blkid…

rmy · Le 10/10/2010, à 21:36

Les paramètres pour grub install, c'est pas dans /usr/lib/grub/i386 plutôt?

spontanément, j'aurais fait ça:
sudo grub-install /dev/md1 --modules=raid,ext2 et si un jour je rajoute mon /boot à mon lvm chiffré, je lui ajouterai lvm, crypto… that's it?
update-initramfs
vgreduce
éteindre,
enlever sda
rebooter.

Par contre, je n'ai pas de grub sur les disques eux-mêmes… et il n'y a rien pour l'instant sur /dev/sdb1 puisque je compte faire un grow en remplaçant mon sda et me retrouver à terme de cette expérimentation avec:
raid 1+0 ((sda1-sdb1)(sdc1-sdd1) pour /boot
raid 5 de 3To sur 4 disques 1To avec Luks+LVM…

Ça va pas coincer? Ça serait pas malin que j'installe grub plutôt sur /dev/sd[bcd]1?

Dernière modification par rmy (Le 10/10/2010, à 21:37)

chopinhauer · Le 10/10/2010, à 21:57

Tu installe Grub sur /dev/sda, /dev/sdb et /dev/sdc, par sur le RAID. Le BIOS ne sait pas lire le RAID, donc Grub doit d'abord accéder à un disque classique pour lire le module raid.mod et en suite monter le RAID.

La différence entre /dev/sda et /dev/sda1 est que sur le dique entier il y a un trou de 31 kio entre le premier secteur du disque et le premier secteur de la première partition. Sur /dev/sda1 il n'y a que 512 octets au plus et après le système de fichiers commence.

Grub est bien plus confortable dans l'espace inutilisé au début de /dev/sda.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#101 Le 07/10/2010, à 19:57

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#102 Le 07/10/2010, à 20:11

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#103 Le 07/10/2010, à 20:14

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#104 Le 07/10/2010, à 20:28

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#105 Le 07/10/2010, à 20:36

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#106 Le 07/10/2010, à 20:46

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#107 Le 07/10/2010, à 20:52

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#108 Le 07/10/2010, à 21:05

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#109 Le 07/10/2010, à 21:30

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#110 Le 07/10/2010, à 21:33

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#111 Le 07/10/2010, à 21:40

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#112 Le 09/10/2010, à 10:42

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#113 Le 09/10/2010, à 10:57

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#114 Le 09/10/2010, à 14:01

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#115 Le 09/10/2010, à 14:06

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#116 Le 09/10/2010, à 15:39

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#117 Le 09/10/2010, à 17:09

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#118 Le 09/10/2010, à 17:22

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#119 Le 09/10/2010, à 19:13

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#120 Le 10/10/2010, à 09:15

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#121 Le 10/10/2010, à 18:49

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#122 Le 10/10/2010, à 19:38

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#123 Le 10/10/2010, à 21:01

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#124 Le 10/10/2010, à 21:36

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

#125 Le 10/10/2010, à 21:57

Re : [reRESOLU] migration lvm chiffré -> raid5+lvm chiffré -> grow disks

Pied de page des forums