LINUX.ORG.RU

Backup зашифрованных разделов LUKS

 , , ,


2

1

Образ всего зашифрованного раздела можно сделать, без проблем. Но как сделать такой образ, чтобы из 160 Гб, к примеру, записались в образ только реальные 15 Гб данных (остальные 145 Гб не заполнены). Clonezilla может это делать, но только не с зашифрованными разделами, как я понял. Это возможно или противоречит самой природе шифрованных разделов? Правильно ли я понял, что в шифрации данных участвует всё выделенное место под раздел?

Если я прав, то это обратная сторона медали шифрованных разделов - придётся тупо копировать всё пространство(.

После открытия шифрованного раздела у тебя появляется незашифрованное блочное устройство в /dev/mapper. Можешь делать его backup, если тебе нужен backup именно раздела.

А вообще покажи вывод lsblk.

Pravorskyi ()
Ответ на: комментарий от anonymous

В том-то и дело, что у меня как раз lvm.

sdb                                             8:16   0 596.2G  0 disk  
├─sdb1                                          8:17   0   953M  0 part  
└─sdb2                                          8:18   0 595.2G  0 part  
  ├─MyNewLVMGroup-swap                        253:1    0   3.7G  0 lvm   
  ├─MyNewLVMGroup-root                        253:2    0  93.1G  0 lvm   
  └─MyNewLVMGroup-home                        253:3    0 498.4G  0 lvm 

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от Pravorskyi

Я с другого диска смотрю просто. Я сделал два основных раздела. Один из них - зашифрован. Его я поделил на 3 логических раздела, объединив их в LVM.

Desmond_Hume ★★★★★ ()
Последнее исправление: Desmond_Hume (всего исправлений: 1)
Ответ на: комментарий от anonymous

Ни borg, ни restic не решат, глянул их возможности. Проблема изначально в том, что есть зашифрованный контейнер и его нужно сохранить, не сохраняя ту часть контейнера, которая пока не заполнена. А это, судя по всему, противоречит сути шифрования разделов. Так что, увы и ах, нужно выбирать что-то одно: удобство и относительную безопасность или неудобства, но надёжность и безопасность. Да уж, дилемма.

Desmond_Hume ★★★★★ ()
Последнее исправление: Desmond_Hume (всего исправлений: 1)
Ответ на: комментарий от Desmond_Hume

Проблема изначально в том, что есть зашифрованный контейнер

В файле, что ли? Потому что если нет, то тебе не нужно «сохранять» весь хренов том. Это крайне глупо.

anonymous ()
Ответ на: комментарий от Desmond_Hume

В этом вся и проблема.

Да, проблема в том, что ты выбрал хреновый способ бэкапа. Долго архивировать, долго восстанавливать, невозможно эффективно хранить множество версий, шанс сохранить в резервной копии какую-нибудь ошибку ФС и прочие способы пострадать от возгорания заднего прохода :)

anonymous ()

Всё просто. Создай зашифрованный раздел для бекапов, а сами бекапы делай на уровне файловой системы, для этого могу порекомендовать borgbackup https://borgbackup.readthedocs.io/en/stable/

Кстати, эта тулза позволяет делать почти то, что ты хочешь, т.е. бекапить только измененные части твоего зашифрованного образа.

anonymous ()
Ответ на: комментарий от anonymous

Нет, не совсем верно ты понял. У меня затея такая: мне нужна безопасность инфы на уровне «украли жёсткий диск». То, что бэкапы можно хранить в шифрованном хранилище - для меня не новость. Та же Clonzilla прекрасно делает шифрование бэкапов. Мне важно, чтобы источник был в шифрованном виде, чтобы даже его кража меня особо не волновала. Ну, украли ноут/комп, и фиг с ним, всё равно прочитать ничего не смогут ...

Desmond_Hume ★★★★★ ()
Ответ на: комментарий от Desmond_Hume

Делай тогда бэкапы LV.

/dev/mapper/MyNewLVMGroup-root
/dev/mapper/MyNewLVMGroup-home

Вот незашифрованные блочные устройства, на которых у тебя ФС с данными. Можешь прямо их бэкапить Clonezilla, указав эти устройства вместо /dev/sdbX.

Такой вариант подходит?

Pravorskyi ()
Ответ на: комментарий от Desmond_Hume

rsync-ом, конечно!

Я лично имею внешний жесткий, зашифрованный тем же луксом. Подключаешь диск, вводишь пароль, дальше

rsync -aiuvHAX --delete-after --dry-run /home/vasya/ /media/homebackup/vasya/

Смотришь глазками, не удаляет ли чего лишнего, потом --dry-run убираешь. Занимает 10 минут от силы

Размеры разделов совпадать не должны, лишь бы места для файлов хватало.

unanimous ★★★★★ ()
Последнее исправление: unanimous (всего исправлений: 1)

чтобы из 160 Гб, к примеру, записались в образ только реальные 15 Гб данных (остальные 145 Гб не заполнены).

По идее, можно включить allow-discards, тогда на месте пустого места будет незашифрованное пустое место. Если trim поддерживается.

TheAnonymous ★★★★★ ()
Ответ на: комментарий от anonymous

ЕМНИП, с файлами-образами так работает - он может быть на 100500 ГБ, но в действительности это будет sparse файл, а реальный объём du image.img - столько, сколько и занято на шифрованной ФС

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

Интересную тему обсуждаете. Позвольте задать вопрос, только не ругайте если я напишу бредятину. Можно ли загрузится с live дистрибутива и смонтировать в cryptsetup корневой раздел который нужно бэкапить? А затем скопировать оттуда файлы все до единого и скрытые файлы и т.д. а когда нужно будет развернуть бэкап то так же смонтировать корневой раздел, сначала удалить там всё содержимое начисто, и после скопировать те файлы которые мы делали для бэкапа?

Deleted ()
Ответ на: комментарий от Deleted

Можно, конечно.
Только копировать лучше rsync-ом (как выше написано), или запаковывать в tar, чтобы права не потерялись.

Ну и на время бекапа, разумеется, всё придётся расшифровывать (чтобы смонтировать cryptsetup нужен пароль/ключ), а носитель для самого бекапа, если требуется, шифровать отдельно (иначе в бекапе данные будут в открытом виде)

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

Можно, конечно.

Только копировать лучше rsync-ом

rsync-ом это прога работающая из под линукс или загрузочная с USB? И еще, у нее есть графический интерфейс?

Deleted ()
Ответ на: комментарий от TheAnonymous

Можно, конечно.

Только копировать лучше rsync-ом (как выше написано), или запаковывать в tar, чтобы права не потерялись.

И еще вопрос, теоретически получается что этим методом в наш шифрованный раздел LUKS можно впихнуть совершенно другой бэкап даже другого дистрибутива линукс который во время создания бэкапа был даже не шифрован или вообще стоял на другой машине?

Deleted ()
Ответ на: комментарий от Deleted

rsync-ом это прога работающая из под линукс

Да

у нее есть графический интерфейс?

Нет

в наш шифрованный раздел LUKS можно впихнуть совершенно другой бэкап даже другого дистрибутива линукс который во время создания бэкапа был даже не шифрован или вообще стоял на другой машине?

Можно, но чтобы он загрузился, надо, чтобы был настроен загрузчик, в fstab всё прописать, также чтоб initrd монтировал шифрованный раздел

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

Только копировать лучше rsync-ом (как выше написано), или запаковывать в tar, чтобы права не потерялись.

Почему копировать лучше rsync-ом?

или запаковывать в tar, чтобы права не потерялись.

Принципиально использовать имеенно формат tar или можно любой другой? И ещё, архиваторы в linux умеют шифровать архивы tar или шифровать следует отдельно?

Для меня терминал дело тёмное, предпочитаю графический интерфейс. Предположим я не буду использовать rsync а пойду по другому пути, использовать архиватор. Сейчас изложу схему действий как я это вижу, поправь меня если я не правильно что то понял. - Загружаемся с live дистрибутива _ Монтирует с помощью cryptsetup наш корневой раздел на жестком диске где установлен наш линукс - Получаем доступ к скрытым файлам в корневом разделе ж. диска, выделяем всё содержимое и добавляем в архив Tar этот архив по завершению архивирования и будет нашим бэкапом - Для разворачивания бэкапа грузимся тоже с live дистрибутива, Монтирует с помощью cryptsetup наш корневой раздел на жестком диске, удаляем всё содержимое этого смонтированного корневого раздела и распаковуем туда архив tar.

Всё правильно?

Deleted ()
Ответ на: комментарий от Deleted

Почему копировать лучше rsync-ом?

Чтобы права и владельцы (а также всякие xattrs и прочее) не потерялись. И чтобы при следующих бекапах не копировать всё содержимое, а только изменённые файлы.

имеенно формат tar или можно любой другой?

Который умеет сохранять unix permissions.
Всякие rar, zip, 7z не подойдут.

шифровать архивы tar или шифровать следует отдельно?

Сам по себе tar - просто контейнер, даже без сжатия. Так что шифровать отдельно, см. gpg, openssl, или там cryptsetup/LUKS на диск, где будет лежать бэкап.

выделяем всё содержимое и добавляем в архив Tar этот архив по завершению архивирования и будет нашим бэкапом

Через терминал.

cd /mnt/linux/ #это куда смонтирован корневой раздел системы
tar --xattrs --acls -czpvf /mnt/backup/bak.tar.gz ./

Для меня терминал дело тёмное, предпочитаю графический интерфейс

Тогда я не знаю, возможно есть какие-то графические утилиты, может кто ещё подскажет.
Если просто копировать через файловый менеджер, то вряд ли что-то получится (хотя бы потому что он обычно работает не от рута)

TheAnonymous ★★★★★ ()
Последнее исправление: TheAnonymous (всего исправлений: 2)
Ответ на: комментарий от TheAnonymous

cd /mnt/linux/ #это куда смонтирован корневой раздел системы

tar --xattrs --acls -czpvf /mnt/backup/bak.tar.gz ./

Выполнил я бэкапы этими командами, вроде получилось, архивы есть. Только в конце выполнения каждого бэкапа вот эта строчка в терминале пишеться - tar: Завершение работы с состоянием неисправности из-за возникших ошибок. Что это такое?

Пробовал восстанавливать бэкапы через архиваторы от рута, есть проблемы, например на не криптованном разделе всё получается без проблем создавать и туда же разворачивать бэкап. А с некриптованого перенес в криптованый, не загружается окружение рабочего стола, тупо чёрный экран, командная строка и всё, еще успел прочитать там что то вроде некоторые директории только для чтения. Не нравиться мне разворачивать бэкап через архиваторы под рутом. Какие команды rsync есть для нормального разворачивания архива tar со всеми правами чтобы было идентично исходнику? Только команды, что куда писать поподробнее если можно, потому что для меня элементарные вещи в терминале не просто даются.

Deleted ()
Ответ на: комментарий от Deleted

Что это такое?

Именно то, что написано, надо смотреть вывод выше, где ошибки.
Можно убрать v из команды tar, чтобы при работе не выводило список всех файлов: tar --xattrs --acls -czpf ...
Бекап делался в рутовой консоли?

с некриптованого перенес в криптованый

загрузчик, ядро, initrd, fstab всё должно быть настроено

для нормального разворачивания архива tar со всеми правами

Почти так же, как создавать, только x вместо c

cd /mnt/linux/
rm -rf .* * #удалить всё содержимое
tar --xattrs --acls -xzpvf /mnt/backup/bak.tar.gz

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

Бекап делался в рутовой консоли?

Да, всё дела в руте, и архиваторы 2 разных с рутом запускал и менеджер файлов в руте чтобы удалить всё с раздела перед разворачиванием бэкапа и терминал естественно под рутом был.

Именно то, что написано, надо смотреть вывод выше, где ошибки.

Можно убрать v из команды tar, чтобы при работе не выводило список всех файлов: tar --xattrs --acls -czpf

Так тоже делал, при создании бэкапа и его разворачивании ошибок не видел, тоесть запускаю команду, жду мин 5, затем появляетя новая строка root@amnesia....... из под Tails всё делал. Для сравнения пробовал делать ранее делать бэкап винды, то там после завершения процесса с командой -xzpvf этого сообщения " tar: Завершение работы с состоянием неисправности из-за возникших ошибок" не было вообще. Что же получаеться тогда? Если я делал бэкап командами tar --xattrs --acls -czpf и не видел ошибок, то бэкап создан нормально или может быть где то битый, не полноценный и т.д.?

Deleted ()
Ответ на: комментарий от TheAnonymous

TheAnonymous, а какие команды нужно вводить чтобы сделать не весь бэкап заново, а лишь записать в существующий архив tar файлы которые отличаются и какими командами это дело разворачивать обратно?

Deleted ()
Ответ на: комментарий от Deleted

бэкап винды

Винду лучше так не бекапить, в NTFS права свои, они так не сохранятся. Винда после такого может и запустится, но последствия могут быть, для бекапа винды лучше свои специализированные средства

Если я делал бэкап командами tar --xattrs --acls -czpf и не видел ошибок

Вроде бы tar, если завершено с ошибками, эту строчку в конце должен выводить, так что по всей видимости бэкап создался нормально.
Можно было бы посмотреть код возврата, сразу после завершения tar следующей командой ввести

echo $?
если там 0 - всё в порядке; если не 0, значит какая-то ошибка

чтобы сделать не весь бэкап заново, а лишь записать в существующий архив tar файлы которые отличаются и какими командами это дело разворачивать обратно?

В существующий tar не получится, насколько я знаю, так что - распаковать tar куда-то (но где файловая система линуксовая, типа ext4), сделать туда rsync, и запаковать в новый tar.

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

В существующий tar не получится, насколько я знаю, так что - распаковать tar куда-то (но где файловая система линуксовая, типа ext4), сделать туда rsync, и запаковать в новый tar.

Как по мне проще заново новый бэкап создать в новый архив, по времени это наверное даже быстрее будет. Что ж, спасибо тебе за помощь! Теперь я знаю как создавать и разворачивать бэкап системы с попощью rsync.

Deleted ()
Ответ на: комментарий от TheAnonymous

Важное исправление

При распаковке архива, чтобы сохранились xattrs, нужно добавлять к параметрам --xattrs-include=*, без этого они при распаковке теряются
Более правильный пример:

cd /mnt/linux/
rm -rf .* * #удалить всё содержимое
tar --xattrs --xattrs-include=* --acls -xzpvf /mnt/backup/bak.tar.gz

Заодно напишу тут свою кулстори.
Недавно как раз понадобилось перенести систему с одного диска на другой. Делалось через tar, практически так же, как было написано в посте здесь. После переноса система заработала, и вроде даже всё в порядке, но вдруг выяснилась одна особенность.
После блокировки экрана в kde вдруг не даёт его разблокировать, говорит неверный пароль - и всё. Я пробую раз 10, по-всякому, перепроверяю capslock, раскладку, даже пробую набирать на экранной клавиатуре - всё пофигу. Я уже думаю, то ли как-то меня взломали, то ли с головой что-то не так.
Потом переключаюсь в tty1 (Ctrl+Alt+F1), а там всё ок, пускает с моим паролем. Выяснилось, что логиниться можно (и в консоли tty, и в иксах в SDDM), нельзя только разблокировать экран, который блокируется в kde (скринсейвером или вручную по Ctrl+Alt+L).
А также, например, от имени пользователя не работает ping, мол недостаточно прав. (тут, наверное, уже многим стало понятно)
Короче, причина в «file capabilities». Сейчас их используют во многих дистрибутивах вместо установки suid-бита, например, для утилиты ping - чтобы разрешить от имени пользователя открывать сырые сокеты и не запускать программу от рута (что типа небезопасно). Аналогично - для какой-то внутренней утилиты из pam, которая проверяет пароль, и без этого не работает и выдаёт ошибку (а kde уже говорит что неверный пароль).
А хранится это всё и работает через xattrs файловой системы. Так что вот такие могут быть побочные действия, если не сохранить их при переносе. Причем заметить можно не сразу, как с блокировкой экрана (если редко ей пользуешься), а потом через несколько дней думать, почему вдруг пароль перестал подходить

TheAnonymous ★★★★★ ()