как хорошо когда есть lvm, я делаю снапшот раздела, запускаю бакап. а в это время продолжаю делать свои дела.

Не надо делать бэкап образом.

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

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

В том-то и дело, что у меня как раз 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 

У меня LVM. Это осложняет дело. Было бы отдельным разделом зашифровано, было бы попроще.

А где у тебя LUKS? В выводе его нет. Каждый раздел отдельно зашифрован?

Покажи вывод lsblk со всеми открытыми контейнерами LUKS.

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

Он, видимо, имеет в виду, что делает нормальный бэкап со снапшота. НЕ через dd. Освой уже borg или restic, они решат все твои проблемы.

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

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

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

Ни borg, ни restic не решат, глянул их возможности.

А ты не пихай в них свой том, бэкапить надо файлы с него.

О файлах речь не идёт. Под «контейнером» имел в виду основной раздел, который зашифрован. В этом вся и проблема.

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

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

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

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

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

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

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

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

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

Не вижу противоречия. Шифруй источник и шифруй приемник. Во время бекапа расшифровывай оба диска и делай бекап на уровне файлов.

А вот это уже ближе к истине. Только как это реализовать ...

В expert-настройках Clonezilla не лазил. Если там есть это, попробую.

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

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

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

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

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

читаю читаю и не оч понятна проблема, если шифровать backup то есть ccrypt например. tar .... | ccrypt -e > /...

Похоже, это лучший совет. Тему закрываю. Буду велосипедить по этому принципу.

Зачем велосипедить? Есть duplicity, например.

присмотрись к bup

Тебе весь тред это пытались вдолбить.

bup говно, obnam помер, теперь кроме borg и restic смотреть нечего.

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

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

тогда на месте пустого места будет незашифрованное пустое место

На большинстве SSD не будет.

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

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

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

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

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

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

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

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

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

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

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

Да

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

Нет

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

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

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

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

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

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

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

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

Почему копировать лучше 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 ./

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

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

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

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

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

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

Вопрос, конечно, риторический, но ты вообще пробовал использовать свой мозг? 🤔

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

Именно то, что написано, надо смотреть вывод выше, где ошибки.
Можно убрать 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

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

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

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

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

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

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

бэкап винды

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

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

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

echo $?

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

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

Зависит от ssd. Пустого места не будет, конечно но нули или по другому шаблону обычно выдавали. Что позволяет сжать быстрым архиватором.

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

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

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

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

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