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/