LVM: Unterschied zwischen den Versionen
Cbs (Diskussion | Beiträge) |
Cbs (Diskussion | Beiträge) |
||
Zeile 260: | Zeile 260: | ||
now you can activate both and access the files on both! | now you can activate both and access the files on both! | ||
+ | |||
+ | perhaps you will have to change the UUID's of the pv and/or vg | ||
+ | |||
+ | pvchange --uuid /physical/volume/path | ||
+ | vgchange --uuid /volume/group/name |
Version vom 7. Dezember 2012, 11:51 Uhr
Inhaltsverzeichnis
future comments
since luks is outdated:
in future use eCryptfs https://launchpad.net/ecryptfs
pakete
apt-get install lvm2 cryptsetup mdadm
raid erzeugen
mdadm -C /dev/md0 -l1 -n2 /dev/sdb1 /dev/sdc1
packt die platten sdb1 und sdc1 in ein raid1 (-l1)
-n2 = 2 raid-member
fuer ein raid5 waere das entsprechend:
mdadm -C /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1
lvm anlegen
pysical volume erzeugen
pvcreate /dev/md0
oder ohne raid:
pvcreate /dev/hda5 /dev/hdc1 /dev/sda2
fuegt die physical volumes hinzu.
bei der verwendung eines raid's muss das device /dev/mdX (z.B. pvcreate /dev/mdX) verwendet werden. |
volume-group erzeugen
vgcreate vg1 /dev/md0
legt die volume-group 'vg1' an. name frei waehlbar
logisches volume erzeugen
lvcreate -L 10G -n <name (z.b. daten)> <vol-group (z.b. vg1)>
wenn verschluesselt werden soll:
cryptsetup -c aes-cbc-essiv:sha256 -y -s256 luksFormat /dev/<vol-grp>/<name> cryptsetup luksOpen /dev/<vol-grp>/<name> daten.decrypted
Physical (encrypted) /dev/<vol-grp>/<name>
Logical (unencrypted) /dev/mapper/daten.decrypted
dateisystem erzeugen
mkfs.ext3 /dev/<vol-grp>/<name>
z.b.:
mkfs.ext3 /dev/vg1/daten
oder falls verschluesselt:
mkfs.ext3 /dev/mapper/daten.decrypted
lvm loeschen
umount [PARTITION] cryptsetup luksClose daten.decrypted dmsetup remove /dev/mapper/vg1-daten lvremove /dev/vg1/daten
lvm vergroessern
groesse der volume-group anzeigen
vgdisplay zeigt volume-group an, also verbleibender/benutzter speicher etc.
ohne den optionalen parameter werden alle volume groups aufgelistet.
vgdisplay [vol-group (z.b. daten)]
logisches volume vergroessern
lvextend -L +100G /dev/vg1/daten
dm-crypt-container vergroessern
wenn verschluesselt, dann den dmcrypt-container vergroessern
cryptsetup resize daten.decrypted
dateisystem vergroessern
danach das filesystem vergroessern...
resize2fs /dev/vg1/daten
wenn verschluesselt:
resize2fs /dev/mapper/daten.decrypted
LVM verkleinern
Reihenfolge beachten um datenverlust zu vermeiden!!! ANYWAY: BE SURE YOU HAVE A BACKUP!! |
nachdem wir die 100G abgezogen haben bleiben noch 50GB in der partition.
diese information ist wichtig fuer die berechnung des wertes am ende des resize2fs commandos
dies ist die angabe der groesse in bloecken.
- dateisystem verkleinern
- ggf. crypted container verkleinern
- lv verkleinern
umount /dev/mapper/daten.decrypted e2fsck -f /dev/mapper/daten.decrypted resize2fs /dev/mapper/daten.decrypted 51200000
wenn verschluesselt nun:
cryptsetup resize daten.decrypted
lvreduce -L-100G /dev/mapper/daten.decrypted mount /dev/mapper/daten.decrypted /dest/path
Platte austauschen
alte platte raus
defekte platte aus raid entfernen
mdadm --remove /dev/md0 /dev/sdd
wenn man (wie ich) 3 gleiche platten eingebaut hat, wie finde ich jetzt die defekte?
ich weiss, es ist sdd, aber welche physikalische platte ist das?
sdparm -i /dev/sdd ... ST31000340AS 9QJ0W04D ...
oder man verwendet lshal
lshal | less
nun nach der defekten platte, also 'sdd' suchen
dann findet man ein paar zeilen weiter unten etwa sowas:
... storage.serial = 'SATA_ST31000340AS_9QJ0W04D' (string) ...
und hat damit die seriennummer der platte 9QJ0W04D
nun also platte raus...
neue platte rein
Falls noetig Partitionstabelle von platte sda auf neue platte sdb uebertragen:
sfdisk -d /dev/sda | sfdisk /dev/sdb
ich denke allerdings ein raid aus platten-partitionen ist eher sub-optimal!
ACHTUNG: bei platten die bereits als raid in benutzung waren! |
das magig-flag am anfang der raid-partition muss ueberschrieben werden:
dd if=/dev/zero of=/dev/sdb5 bs=1024 count=1000
bzw:
dd if=/dev/zero of=/dev/sdd bs=1024 count=1000
raid-partition zu mdX hinzufuegen bzw. ganzes device:
mdadm /dev/md0 -a /dev/sdb1
bzw:
mdadm /dev/md0 -a /dev/sdd
replication abwarten:
watch 'cat /proc/mdstat'
... [>....................] recovery = 4.1% (40587520/976761408) finish=227.8min ...
Raid-Status
cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb5[1] sda5[0] 155999040 blocks [2/2] [UU] unused devices: <none>
ausgabe bei inconsitenz oder fehlender platte:
cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sda5[0] 155999040 blocks [2/1] [U_] unused devices: <none>
mit folgendem kommando kann wird die ausgabe staendig refreshed:
watch cat /proc/mdstat
LVM Snapshot/Backup
erstelle ein backup eines logischen volumes.
dies wird hauptsaechlich zum backup von mysql benutzt. ich fuehre also die
schritte, die innerhalb von mysql benoetigt werden, hier mit auf...
mysql-datenbanken locken damit die files consistent sind:
mysql> FLUSH TABLES WITH READ LOCK
dies kann einen moment dauern.
wenn das kommando durch ist, die mysql-connection offen lassen!
nun:
lvcreate -L16G -s -n dbbackup /dev/vg1/mysqlPartition
dies erzeugt eine kopie der lvm-partition die die datenbanken enthalten.
bei der groesse (-L16G) muss man natuerlich darauf achten dass partition f. die kopie
gross genug ist um die daten in /dev/vg1/mysqlPartition aufzunehmen.
danach haben wir eine kopie unserer partition /dev/vg1/mysqlPartition unter /dev/vg1/dbbackup
zurueck zur datenbank und tabellen frei geben.
falls die DB repliziert ist muss man zusaetzlich noch die log-position sichern:
mysql> SHOW MASTER STATUS; ... mysql> UNLOCK TABLES;
nun kann man ganz gemuetlich die backup-partition mounten und die daten kopieren.
die datenbank laeuft derweil ganz normal weiter...
mount /dev/vg1/dbbackup /mnt/backup cp /mnt/backup/mysql/* /path/to/backups
or whatever you want...
if ready, unmount the partition and destroy it...
umount /mnt/backup lvremove /dev/vg1/dbbackup
thats it! ;-)
LVM volume group collissions
if you put a disk to another system, and the system has a volume group
of the same name as on the newly attached disk, you will run into trouble... ;-)
you will see log messages like:
[lvm] WARNING: Duplicate VG name vg00: Existing ribPzO-611T-0Cdc-SBi0-iV78-27xy-VCjaAt (created here) takes precedence over ribPzO-611T-0Cdc-SBi0-iV78-27xy-VCjaAt
vgrename command with UUID does not wort!!
so, renaming the first (production) VG into whatever,
then renaming the second (NON-production) VG into final name
and renaming back the first (production) VG into it's old name will solve the problem...
vgrename vg02 my_new_volume_group_name
now you can activate both and access the files on both!
perhaps you will have to change the UUID's of the pv and/or vg
pvchange --uuid /physical/volume/path vgchange --uuid /volume/group/name