Ручной бэкап encrypted LVM on LUKS

Доброго времени суток.
Проконсультируйте как грамотно забэкапить/заснапшотить (и как восстанавливать из резервной копии/снапшота), а то боязно криво сделать, хоть и читал "вику":

Arch at LVM on LUKS (f2fs)
sda 8:0 0 111,8G 0 disk
└─sda1 8:1 0 111,8G 0 part
└─cryptlvm 254:0 0 111,8G 0 crypt
├─V00-lvolroot 254:1 0 40G 0 lvm /
├─V00-lvolswap 254:2 0 3G 0 lvm [SWAP]
└─V00-lvolhome 254:3 0 68,8G 0 lvm /home
sdb 8:16 1 983M 0 disk
└─sdb1 8:17 1 300M 0 part /boot
(бут на флэхе, груб)

Как сделать бэкап всего LVM (снапшоты) на отдельную флэху, также отформатированную в f2fs?
Нужно ей дать LUKS ключи к cryptlvm? Если можно подробнее.
Проверьте, компетентные люди:

#гружуcь с live флэшки, распароливаю хард, не монтирую ничего

#т.к. весь хард занят одним LVМ, удаляю своп-раздел
lvremove lvol-swap
#создаю lvol-swap 1G
lvcreate /dev/mapper/lvol-swap
#заново создаю своп-раздел lvol-swap меньшего размера - 1G
#создаю снэпшоты корня и хомяка
sync
lvcreate  -L 1G /dev/mapper/lvol-swap
lvcreate -s -n root-snap-lv -L 1G /dev/mapper/V00-lvolroot
lvcreate -s -n home-snap-lv -L 1G /dev/mapper/V00-lvolhome

#в mnt создаю точки монтирования для новых лог. томов
mkdir /mnt/backups/root-snap
mkdir /mnt/backups/home-snap

# монтирую
mount /dev/mapper/root-snap-lv /mnt/backups/root-snap
mount /dev/mapper/home-snap-lv /mnt/backups/home-snap

#на внешней флэхе создаю 2 раздела по 1G, формат в f2fs (sdc1, sdc2)
#1 раздел 500М для бута на флэхе (sdc3)
#монтирую в
/mnt/USB/root-backup
/mnt/USB/home-backup
/mnt/USB/boot-backup

#копирую на флэшку
dd if=/dev/mapper/root-snap-lv of=/dev/sdc1/snap_root bs=20M
dd if=/dev/mapper/home-snap-lv of=/dev/sdc2/snap_home bs=20M
rsync -a /boot/ /dev/sdс3/boot-backup/

#восстановление:
# при крахе системы в ту же (такую же) группу V00 - текущего или нового харда
# создаю разделы для рута и хомяка, форматирую в f2fs
lvconvert --merge /dev/mapper/root-snap-lv
lvconvert --merge /dev/mapper/home-snap-lv
#удаление LV
lvremove /dev/mapper/root-snap-lv
lvremove /dev/mapper/home-snap-lv

Все корректно и что надо использовать dev/mapper/root-snap-lv или /dev/V00/root-snap-lv ?
Давно не занимался шифрованием HDD, пока не понял, что это баловство и абсолютно лишнее. Имеются более надежные и простые способы хранения ценной информации. Но, как говорится, хозяин барин.
Если честно не совсем понял, что описано, да и не понятно назначение backup.
PS - В принципе, по идее все правильно, но тщательно не проверял
Мало кто шифрует разделы, тем более диски. НО backup в этом случае обязательно нужен и он нужнее, чем в обычной системе.
Но все зависит от объема и периодичности backup, правда, как правило, стараются делать backup как можно реже, да и если шифруется HDD/раздел, то обычно назначение у них другое и обновление не значительное, а потому и нет смысла делать это часто.
Насчет способов - есть неплохие утилиты - удобно и никаких проблем.
Ручные способы - как правило, backup делается для надежности и сохранности информации, а значит используются и простые, надежные способы - дешифровка, копирование, раздел/файл Tryecrypt … можно и другие, например dd, rsync.

А вообще, с шифрованными данными обращаются осторожно. И раньше, когда этим занимался, перед тем как что то забэкапить, дважды проверял на небольшом объеме. Что и тебе рекомендую сделать.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Давно не занимался шифрованием HDD, пока не понял, что это баловство и абсолютно лишнее. Имеются более надежные и простые способы хранения ценной информации. Но, как говорится, хозяин барин.
Если честно не совсем понял, что описано, да и не понятно назначение backup.
PS - В принципе, по идее все правильно, но тщательно не проверял
Мало кто шифрует разделы, тем более диски. НО backup в этом случае обязательно нужен и он нужнее, чем в обычной системе.
Но все зависит от объема и периодичности backup, правда, как правило, стараются делать backup как можно реже, да и если шифруется HDD/раздел, то обычно назначение у них другое и обновление не значительное, а потому и нет смысла делать это часто.
Насчет способов - есть неплохие утилиты - удобно и никаких проблем.
Ручные способы - как правило, backup делается для надежности и сохранности информации, а значит используются и простые, надежные способы - дешифровка, копирование, раздел/файл Tryecrypt … можно и другие, например dd, rsync.

А вообще, с шифрованными данными обращаются осторожно. И раньше, когда этим занимался, перед тем как что то забэкапить, дважды проверял на небольшом объеме. Что и тебе рекомендую сделать.
Вот поэтому про ручной способ и пишу - что максимально надёжно, а LVM позволяет сделать снимок всего раздела, а не по отдельности rsync-ом дергать, исключая ненужное, тем более что места снимок занимает в разы меньше самого раздела. Раз в неделю такого бэкапа мне достаточно, т.к. основные доки бэкаплю отдельно. Настраивать все не хотелось бы заново - софт для человека, а не человек для софта. Зарыта ошибка в DMA у меня - то ли северный мост на материнке, то ли разъем барахлят. 2 SSD сменил, 2 HDD проверял - одна и та же история. Приходит время апгрейда, но пока не до него. А ошибка такая:

        ata1.00: exception Emask 0x50 SAct 0x0 SErr 0x40d0802 action 0xe frozen
kernel: ata1.00: SError: { RecovComm HostInt PHYRdyChg CommWake 10B8B DevExch }
kernel: ata1.00: failed command: READ DMA
kernel: ata1.00: cmd c8/00:08:68:89:d2/00:00:00:00:00/ed tag 0 dma 4096 in
                              res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x54 (ATA bus error)
12:02:37 kernel: ata1.00: status: { DRDY }
Поэтому бэкап необходим.
Что можно более надежное и простое использовать для хранения ценной информации?
Singletary
Раз в неделю такого бэкапа мне достаточно, т.к. основные доки бэкаплю отдельно.
Все понятно. Но все-таки зря не обратишь взор на утилиты, есть довольно хорошие, правда из винды. Из под Linux раньше, если не ошибаюсь, с шифрованными дисками нормально работал PartImage. Как сейчас, не знаю.

В части сообщений libata - немного расшифрую вывод, может пригодится, когда будешь анализировать
1. Eception line
ata1.00: exception Emask 0x50 SAct 0x0 SErr 0x40d0802 action 0xe frozen
Emask 0x50 - точно не помню, но обычно на это не смотрят
frozen - if present, indicates the port was frozen for EH (Error Handler)
2. Расширенный вывод Serror - в данном случае намного интереснее
ata1.00: SError: { RecovComm HostInt PHYRdyChg CommWake 10B8B DevExch }
RecovComm - Communications between device and host temporarily lost, but regained
HostInt - Host bus adapter internal error
PHYRdyChg - PhyRdy signal changed state
CommWake - COMWAKE detected by PHY (PHY woken up)
10B8B - 10b to 8b decoding error occurred
DevExch - Device presence has changed
и указывает на проблему аппаратного обеспечения, точнее временное отсоединение привода - как правило, это плохой кабель SATA, плохой источник питания).
3. cmd - вообщем то ничего не выудим, кроме как видим, что отключен/не активен NCQ
ata1.00: cmd c8/00:08:68:89:d2/00:00:00:00:00/ed tag 0
tag 0 - NCQ tag number, or listed as zero if NCQ is not active/applicable
4. error summary, еще раз подтверждает аппаратную проблему, указанную выше
res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x54 (ATA bus error)
ATA bus error - chip<->device bus error

UPD - забыл status: { DRDY } .... DRDY - Device ready. Normally 1, when all is OK.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Singletary
Раз в неделю такого бэкапа мне достаточно, т.к. основные доки бэкаплю отдельно.
Все понятно. Но все-таки зря не обратишь взор на утилиты, есть довольно хорошие, правда из винды. Из под Linux раньше, если не ошибаюсь, с шифрованными дисками нормально работал PartImage. Как сейчас, не знаю.

В части сообщений libata - немного расшифрую вывод, может пригодится, когда будешь анализировать
1. Eception line
ata1.00: exception Emask 0x50 SAct 0x0 SErr 0x40d0802 action 0xe frozen
Emask 0x50 - точно не помню, но обычно на это не смотрят
frozen - if present, indicates the port was frozen for EH (Error Handler)
2. Расширенный вывод Serror - в данном случае намного интереснее
ata1.00: SError: { RecovComm HostInt PHYRdyChg CommWake 10B8B DevExch }
RecovComm - Communications between device and host temporarily lost, but regained
HostInt - Host bus adapter internal error
PHYRdyChg - PhyRdy signal changed state
CommWake - COMWAKE detected by PHY (PHY woken up)
10B8B - 10b to 8b decoding error occurred
DevExch - Device presence has changed
и указывает на проблему аппаратного обеспечения, точнее временное отсоединение привода - как правило, это плохой кабель SATA, плохой источник питания).
3. cmd - вообщем то ничего не выудим, кроме как видим, что отключен/не активен NCQ
ata1.00: cmd c8/00:08:68:89:d2/00:00:00:00:00/ed tag 0
tag 0 - NCQ tag number, or listed as zero if NCQ is not active/applicable
4. error summary, еще раз подтверждает аппаратную проблему, указанную выше
res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x54 (ATA bus error)
ATA bus error - chip<->device bus error

UPD - забыл status: { DRDY } …. DRDY - Device ready. Normally 1, when all is OK.
Точно, скорее всего кабель/скачки напряжения. Спасибо.
Так а более надежное и простое для хранения ценной информации что рекомендуешь?
Singletary
Что можно более надежное и простое использовать для хранения ценной информации?
Забыл ответить в прошлом посту, увлекся сообщениями libata.

Вот зачем шифровать весь диск? Он же не содержит 100% важной информации. Это же можно сказать, в принципе, и о разделе.
Все зависит от объема и вида информации. Вкратце.
Например, вот зачем хранить важные пароли и им подобное (например, номера счетов, pin-коды, номера телефонов и др.) в зашифрованном диска. Например, я часто использую online-bank (платежи, переводы - все не выходя из дома), а если куда уезжаю, беру эту инфу с собой (всегда может понадобиться, могу даже использовать на компе с виндой). Использую для этого KeePass. Плюс еще и в том, что можно назначать время хранения в памяти при копировании (например 30с, после чего удаляется из памяти, что очень важно при использовании на чужом компе. Для хранения паролей можно использовать и другие способы, о которых вообще мало кто знает.
Текстовую/графическую информацию большого объема лучше хранить в зашифрованных файлах-контейнерах - способов несколько, при этом все работает динамически.

UPD - не нужно приводить всю ссылку, лучше только нужное. Меньше занимает места и легче читается.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Вот зачем шифровать весь диск?
Иногда это необходимо, например, при накоплении тысяч файлов на сотни мегабайт. И наличие автологина компенсируется распароливанием/ключами. Да, вскрывается при большом желании и все же для основной деятельности более менее надежно. По отдельности делать файл-контейнеры несколько трудозатратно. KeePass удобная утилита, юзаю.
Singletary
Иногда это необходимо, например, при накоплении тысяч файлов на сотни мегабайт.
А не проще воспользоваться ecryptfs (модуль ecryptfs встроен в ядро) - шифрование на уровне файловой системы. Создаешь директорию, закидываешь туда кучу файлов и вперед. Преимущества - скорость, инкрементальный бэкап и др. Описывать не буду - смотри Wiki, googl.

UPD - довольно надежное шифрование (по умолчанию 128-битный вариант)
Ошибки не исчезают с опытом - они просто умнеют
vasek
А не проще воспользоваться ecryptfs
Спасибо, гляну. Пока надо с бэкапами разобраться.
 
Зарегистрироваться или войдите чтобы оставить сообщение.