Использование мгновенных снимков LVM (Snapshots, снапшоты) при работе с базами данных позволяет создавать резрвные копии без остановки баз данных. Скорость при создании снапшота выше, чем при использовании внутренних утилит резервного копирования баз данных
mongolvmbackup.sh
Список команд для создания снапшота
lvscan
sudo lvcreate -L 100G -p r -s -n lv1_data_snap /dev/vg/lv1
lvscan
lsblk
mount -r /dev/vg/lv1_data_snap /mnt
mount -o nouuid,ro /dev/vg/lv1_data_snap /mnt
tar czf /backup_lv1/backup_lv1.tgz backup_lv1
umount /mnt
lvremove vg/lv1_data_snap
lvscan
tar -tvzf billingmongo.tgz >/dev/null && echo “Backup is good!”
lvscan
sudo lvcreate -L 100G -s -n lv_agis_snap /dev/vg1/lv1
lvscan
lsblk
mount -o nouuid,ro -r /dev/vg1/lv_agis_snap /mnt
tar czf backup_lv1.tgz backup_lv1
umount /mnt
lvremove -f vg1/lv_agis_snap
lvscan
lvscan
sudo lvcreate -L 100G -s -n lv2_data_snap /dev/vg1/lv1
lvscan
mount -r /dev/vg1/lv1_data_snap /backup_lv1
tar czf backup_lv1.tgz backup_lv1
umount /backup_lv1
lvremove vg1/lv1_data_snap
lvscan
Детальное объяснение
https://www.8host.com/blog/rezervnoe-kopirovanie-dannyx-mysql-v-xranilishhe-s-pomoshhyu-snapshotov-lvm/
https://help.ubuntu.ru/wiki/samba_shadow_copy
1. Проверить точки монтирования – lsblk
root@dump:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 93.9M 1 loop /snap/core/9066
loop1 7:1 0 93.8M 1 loop /snap/core/8935
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 1M 0 part
└─sda2 8:2 0 931.5G 0 part /
sdb 8:16 0 931.5G 0 disk
├─vg1-lv1 253:0 0 40G 0 lvm /lv1
└─vg1-lv2 253:1 0 30G 0 lvm /lv2
2. Выясним, сколько физических томов используется:
root@dump:~# pvscan
PV /dev/sdb VG vg1 lvm2 [931.50 GiB / 861.50 GiB free]
Total: 1 [931.50 GiB] / in use: 1 [931.50 GiB] / in no VG: 0 [0 ]
Как видите, в данном случае есть один физический том объемом 931.5 ГБ (/dev/sdb), который находится в группе томов vg1. 70 ГБ (=931.5-861.5) этого физического объема выделено на логические тома, а 861.5 ГБ остается свободным для использования группой томов.
3. Чтобы подтвердить это, запросите подробные данные о группе томов vg1, используя команду vgdisplay:
root@dump:~# vgdisplay
— Volume group —
VG Name vg1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 931.50 GiB
PE Size 32.00 MiB
Total PE 29808
Alloc PE / Size 2240 / 70.00 GiB
Free PE / Size 27568 / 861.50 GiB
VG UUID qlz28u-gWGz-tAQc-Ppju-W171-Q281-jfpe3B
PE – physical extent 32Mb. 2240*32/1024=70 27568*32/1024=861.5
Строка Cur PV показывает, что в этой группе томов есть 1 физический том. Строка Cur LV указывает, что пул пространства в этой группе томов был использован для создания 2 логических томов.
4. Чтобы посмотреть на эти логические тома, используйте lvdisplay:
root@dump:~# lvdisplay
— Logical volume —
LV Path /dev/vg1/lv1
LV Name lv1
VG Name vg1
LV UUID XoRccj-4f5I-nbW4-e8SG-vJIN-Rxdz-P9QDH3
LV Write Access read/write
LV Creation host, time dump, 2020-05-26 22:45:03 +0600
LV Status available
# open 1
LV Size 40.00 GiB
Current LE 1280
Segments 2
Allocation inherit
Read ahead sectors auto
– currently set to 256
Block device 253:0
— Logical volume —
LV Path /dev/vg1/lv2
LV Name lv2
VG Name vg1
LV UUID cJfsbv-oiF1-qg1v-OGfd-xhut-NdLa-ZCv6L8
LV Write Access read/write
LV Creation host, time dump, 2020-05-26 22:45:16 +0600
LV Status available
# open 1
LV Size 30.00 GiB
Current LE 960
Segments 1
Allocation inherit
Read ahead sectors auto
– currently set to 256
Block device 253:1
LV Size сообщает, что у нас есть логический том объемом 40 ГБ, lv1, расположенный в /dev/vg1/lv1 (напомним, что vg1 – имя группы томов).
Подводя итог, следует сказать, что на сервере Ubuntu 18.04, используемом в этом мануале, есть один физический том объемом 931.50 ГБ (/dev/sdb), используемый для поддержки одной группы томов (vg1), из которой был создано два логических тома объемом 40 и 30 ГБ (lv1 и lv2). Это оставляет 861.50 ГБ свободного места группе томов, которое может использоваться для создания дополнительных логических томов и снапшотов.
5. Теперь нужно подготовить сервер базы данных к созданию снапшота LVM.
Чтобы создать корректный снапшот LVM, необходимо обеспечить достаточное дисковое пространство для любых записей или изменений, которые могут возникнуть во время резервного копирования и передачи файлов в хранилище. В зависимости от размера вашей базы данных резервное копирование может занять несколько часов, поэтому лучше не забывать про осторожность. Если в процессе выполнения резервного копирования в томе заканчивается пространство, то том снапшота станет недействительным, и вы не получите последовательную резервную копию.
В предыдущем разделе вы узнали, что группа томов (vg1), содержащий два логических тома (lv1 и lv2), имеет свободного пространства 861.50 ГБ. В производственной настройке лучше всего измерить средний объем данных, записываемых на диск во время запланированного резервного копирования, и соответственно масштабировать размер тома снапшота.
Чтобы добавить дополнительные пространства в группу томов vg1, можно либо добавить блочное устройство хранения, либо увеличить размер тома, который в настоящий момент подключен к серверу.
6. Создание и монтирование снапшота LVM
Важно! Во время создания снапшота LVM при записи на диск будет некоторое ухудшение производительности. Вы должны сначала протестировать эту процедуру на тестовой базе данных с симулированной нагрузкой, чтобы убедиться, что этот метод будет работать в производственной среде.
Теперь нужно создать снапшот логического тома lv1, используя lvcreate. В зависимости от баз данных можно морозить или не морозить запись в базу данных
7. Создание и монтирование тома снапшота
Теперь мы можем сделать снимок логического тома vl1. Выделите 100 ГБ буферного пространства для обработки записей и других изменений при выполнении физической резервной копии. Чтобы создать снимок LVM, выполните следующую команду lvcreate:
sudo lvcreate -L 100G -s -n lv1_data_snap /dev/vg1/lv1
Флаг -L указывает размер логического тома, в данном случае это 100 ГБ. Флаг -s указывает, что логическим томом будет снапшот, в этом случае это снапшот тома /dev/vg1/lv1. Назовем этот том lv1_data_snap.
Вы увидите такой вывод:
root@dump:~# lvcreate -L 100G -s -n lv1_data_snap /dev/vg1/lv1
Using default stripesize 64.00 KiB.
Reducing COW size 100.00 GiB down to maximum usable size <40.19 GiB.
Logical volume “lv1_data_snap” created.
Это указывает на то, что теперь у вас есть копия логического тома lv1, из которой можно выполнить резервное копирование.
То, что снапшот создался, можно проверить десятком способов. Попробуйте, например, следующие команды:
# lvscan
# lvdisplay /dev/vg1/lv1
# lvdisplay /dev/vg1/lv1_data_snap
# ls -al /dev/vg1
root@dump:/# lvscan
ACTIVE Original ‘/dev/vg1/lv1’ [40.00 GiB] inherit
ACTIVE ‘/dev/vg1/lv2’ [30.00 GiB] inherit
ACTIVE Snapshot ‘/dev/vg1/lv1_data_snap’ [<40.19 GiB] inherit
root@dump:/# lvdisplay /dev/vg1/lv1
— Logical volume —
LV Path /dev/vg1/lv1
LV Name lv1
VG Name vg1
LV UUID XoRccj-4f5I-nbW4-e8SG-vJIN-Rxdz-P9QDH3
LV Write Access read/write
LV Creation host, time dump, 2020-05-26 22:45:03 +0600
LV snapshot status source of
lv1_data_snap [active]
LV Status available
# open 1
LV Size 40.00 GiB
Current LE 1280
Segments 2
Allocation inherit
Read ahead sectors auto
– currently set to 256
Block device 253:0
root@dump:/# lvdisplay /dev/vg1/lv1_data_snap
— Logical volume —
LV Path /dev/vg1/lv1_data_snap
LV Name lv1_data_snap
VG Name vg1
LV UUID STCjI2-D2Qz-YdDb-7Lz4-Y5SL-3BPv-vP17ay
LV Write Access read/write
LV Creation host, time dump, 2020-05-30 13:42:16 +0600
LV snapshot status active destination for lv1
LV Status available
# open 0
LV Size 40.00 GiB
Current LE 1280
COW-table size <40.19 GiB
COW-table LE 1286
Allocated to snapshot 0.01%
Snapshot chunk size 4.00 KiB
Segments 1
Allocation inherit
Read ahead sectors auto
– currently set to 256
Block device 253:4
root@dump:/# ls -al /dev/vg1
total 0
drwxr-xr-x 2 root root 100 May 30 13:42 .
drwxr-xr-x 19 root root 3920 May 30 13:42 ..
lrwxrwxrwx 1 root root 7 May 30 13:42 lv1 -> ../dm-0
lrwxrwxrwx 1 root root 7 May 30 13:42 lv1_data_snap -> ../dm-4
lrwxrwxrwx 1 root root 7 May 28 01:25 lv2 -> ../dm-1
8. Теперь, когда мы по существу «заморозили» наши файлы данных базы данных в определенный момент времени, мы можем разблокировать таблицы базы данных и возобновить операции записи.
Таблицы разблокированы.
На данный момент ваша БД все еще работает и принимает входящие соединения и записи. Также у вас есть последовательный снапшот данных в тот момент, когда вы запускали заморозку записи в базу данных. Точнее, данных в момент времени, когда был обработан последний запрос записи.
На этом этапе нужно смонтировать снапшот, чтобы у вас был доступ к замороженным данным.
Создайте точку монтирования /backup_lv1:
sudo mkdir /backup_lv1
Смонтируйте том снапшота в /backup_src:
root@dump:~# sudo mount -r /dev/vg1/lv1_data_snap /backup_lv1
root@dump:~# mount | grep lv1
/dev/mapper/vg1-lv1 on /lv1 type ext4 (rw,relatime,data=ordered)
/dev/mapper/vg1-lv1_data_snap on /backup_lv1 type ext4 (ro,relatime,data=ordered)
Я монтирую с опцией -r (read only), поскольку LVM позволяет писать на снапшоты, но нам это не нужно. Поэтому лучше сразу себя обезапасить от неожиданностей.
Теперь у вас есть доступ к замороженным данным. Проверьте это:
root@dump:~# cd /backup_lv1/
root@dump:/backup_lv1# ls -l
total 420
-rw——- 1 999 docker 36864 May 27 20:39 collection-0-1096146680539656498.wt
-rw——- 1 999 docker 20480 May 29 16:15 collection-0-5859158363119544826.wt
-rw——- 1 999 docker 53248 May 29 16:15 collection-2-5859158363119544826.wt
-rw——- 1 999 docker 24576 May 27 22:03 collection-4-5859158363119544826.wt
drwx—— 2 999 docker 4096 May 29 16:15 diagnostic.data
-rw-r–r– 1 999 root 273 May 26 22:51 hosts
-rw——- 1 999 docker 36864 May 27 20:36 index-1-1096146680539656498.wt
-rw——- 1 999 docker 20480 May 29 16:15 index-1-5859158363119544826.wt
-rw——- 1 999 docker 36864 May 29 16:15 index-3-5859158363119544826.wt
-rw——- 1 999 docker 12288 May 28 00:36 index-5-5859158363119544826.wt
-rw——- 1 999 docker 12288 May 29 16:15 index-6-5859158363119544826.wt
drwx—— 2 999 docker 4096 May 29 16:12 journal
drwx—— 2 999 root 16384 May 26 22:49 lost+found
-rw——- 1 999 docker 36864 May 29 16:15 _mdb_catalog.wt
-rw——- 1 999 docker 0 May 29 16:15 mongod.lock
-rw——- 1 999 docker 36864 May 29 16:15 sizeStorer.wt
-rw——- 1 999 docker 114 May 27 14:22 storage.bson
-rw——- 1 999 docker 46 May 27 14:22 WiredTiger
-rw——- 1 999 docker 4096 May 29 16:15 WiredTigerLAS.wt
-rw——- 1 999 docker 21 May 27 14:22 WiredTiger.lock
-rw——- 1 999 docker 1252 May 29 16:15 WiredTiger.turtle
-rw——- 1 999 docker 45056 May 29 16:15 WiredTiger.wt
9. Теперь можно скопировать снимок в хранилище объектов.
Теперь сожмите и загрузите каталог данных MySQL в mysql-backup-demo:
root@dump:/# cd /
root@dump:/# tar -czf backup_lv1.tgz backup_lv1
root@dump:/# ls -l /backup_lv1.tgz
-rw-r–r– 1 root root 6266562 May 30 13:33 /backup_lv1.tgz
10. Демонтаж и сброс тома снапшота
Теперь, когда данные были архивированы, том снапшота, который мы создали ранее в этом учебнике, больше не используется, и его можно безопасно размонтировать.
Для этого введите:
root@dump:/# umount /backup_lv1
Чтобы сбросить том, введите:
sudo lvremove vg1/lv1_data_snap
Здесь vg1 – это имя вашей группы томов, а lv1_data_snap – имя вашего снапшота.
Вам будет предложено подтвердить удаление, для этого нужно ответить Y.
Вы должны увидеть следующий результат:
root@dump:/# sudo lvremove vg1/lv1_data_snap
Do you really want to remove and DISCARD active logical volume vg1/lv1_data_snap? [y/n]: y
Logical volume “lv1_data_snap” successfully removed
Том снапшота успешно удален. Теперь вы завершили полное физическое резервное копирование базы данных и загрузили его в свое удаленное хранилище.
How to: Mounting an XFS LVM snapshot
Your objective is to mount a LVM snapshot where the origin is a XFS filesystem. On mounting the snapshot to its mount point you get the following feedback:
[root@server0 ~]# mount /dev/mapper/VG_DB-SNAP_MARIA /backups/maria/
mount: wrong fs type, bad option, bad superblock on /dev/mapper/VG_DB-SNAP_MARIA,
missing codepage or helper program, or other error
In some cases useful info is found in syslog – try
dmesg | tail or so.
If you notice the feedback, it suggests to run the dmesg command and you notice the following:
[86803.183360] XFS (dm-1): Filesystem has duplicate UUID 9e92f93c-1b03-4383-b753-ae4b449b6864 – can’t mount
If you didn’t notice that, and checked /var/log/messages you would see something similar:
Feb 25 11:05:14 localhost kernel: XFS (dm-1): Filesystem has duplicate UUID 9e92f93c-1b03-4383-b753-ae4b449b6864 – can’t mount
There are 2 things that you can do:
[1] Mount the filesystem without using its UUID
mount -o nouuid mount /dev/mapper/VG_DB-SNAP_MARIA /backups/maria/
or:
[2] Change the UUID of the snapshot LVM
xfs_repair -L /dev/mapper/VG_DB-SNAP_MARIA
xfs_admin -U $(uuidgen) /dev/mapper/VG_DB-SNAP_MARIA
mount /dev/mapper/VG_DB-SNAP_MARIA /backups/maria/