Рациональный бекап системных директорий роллинга

Поделитесь вашими соображениями.

NixOS решает, че.

Интересная система, пробовал ее в виртуалке. Но для меня неоправданно сложная. Разобраться то я конечно разберусь, только времени это займет достаточно, чтобы отказаться от этой идеи заранее. Ну и проблемы nix конфигурации по разным программам тоже никто пока не отменял. Может лет через 5 когда более-менее будут допилены конфиги разных прикладных программ в nix, тогда может быть попробую nixos.

Меня archlinux устраивает. Не ищу другие дистрибутивы. Просто хочу сделать некую подушку, чтобы если что - всегда мог быстро вернуться к работе.

Не бэкапь систему, Configuration as a Code вместо этого, ansible, например.

Я делаю бекапы с помощью rsync с SSD на HDD. Использую опцию --link-dest, с ротацией на bash-скрипте. В результате хранится 5 последний дней, но места занимает меньше.

могут сильно разрастить при ежедневных снимках

Можно делать не каждый день. Либо с разной периодичностью, например, /home каждый день, а / через 2.

Прочитал на вики про ansible. Не понял, как он мне поможет/какую проблему решит. Уточнишь?

в свежем образе может оказаться такая же проблемная версия программы, которая привела к неработоспособности системы…

…поэтому, сначала делаешь бэкап, а потом «изменяешь-ломаешь систему».

быстро переустановить систему из свежего среза

Еще быстрее, бэкап и есть запасная система, запускаешь ее и работаешь. Во время перекура можно и восстановить прямо из нее. А так как это «живая система», то и экспериментировать безопасней на ней. Все огрехи лечатся перезагрузкой.

Я еще почитал про LVM, т.к. до этого не пользовался им, и посмотрел примеры снапшотов. Оказывается, я немного неправильно оценил ситуацию. Если делать снапшот, то все изменения после создания снапшота пишутся в сам снапшот, а не в основную систему. Чтобы перенести изменения из снапшота, его нужно объединения с основной системой. Значит мне будет достаточно сделать один снапшот и работать через него до тех пор, пока я не убежусь, что программы работают штатно. Потом объединить снапшот с основной системой. Только нужно заранее предусмотреть в lvm группе неиспользованное под lvm том места под снапшот. Сделать что-то вроде

/boot/efi - fat32
/boot - ext4
/ - lvm 1 том + свободные 10-15 Гб в той же lvm группе
/home - ext4

Поправьте, если я все еще не прав.

По сути, сломаться могут две вещи: /boot и база данных установленных пакетов (/var/). Полагаю, что их и надо бэкапить. /etc должен бэкапиться отдельно, а все остальное можно восстановить переустановкой пакета.

Извини, опять оффтоп, сильверблю. Поищи, может есть что-то другое на этой технологии, если шляпники тебе совсем не идут. ostree снимает твою проблему. Вроде бтрфс тоже должен, но пока не ясно.

BTRFS не вариант <…> Хотелось бы оставаться с проверенными временем фсами <…>

Ну ССЗБ, страдай тогда.

проверенными временем фсами

вроде ext2

Пацталом!!!

Запасная система интересная мысль, но это еще одна точка отказа. Ее тоже придется держать в актуальном состоянии, например, потому, что обновленые версии программ могут не так работать с конфигами старых версий, тоже касается работы с документами, они в старых версиях могут не так отображаться. Плюс нужно постоянно синхронизировать набор программ на обеих системах, что с учетом специфики роллинг дистрибутивов предполагает постоянные обновления системы.

Пацталом!!!

Там и оставайся. Всего доброго.

можно восстановить переустановкой пакета.

Случаи, когда сломался какой-то несистемный пакет, а система продолжает нормально функционировать, конечно, решаются простым даунгрейдом пакета, например, из кеша в /var. Но если ситсема вообще не загружается? Если некогда искать причину или она неочевидна? Конечно, если дело просто в новом ядре, то можно переключится на другое ядро (лтс, зен и т.п.), но может быть проблема с инициализацией, может быть испорчен initrd и прочее и прочее. Вот от таких вещей я и страхуюсь.

Точка отказа - это «роллинг». Этот момент я немного упустил. Хотя, по сути в моей схеме он ничего не меняет. Запасная система актуальна на момент ее создания. Следующая актуальная система - следующий бэкап. Это одинаково при любом способе сохранения. Как-раз проявляется гибкость. Если изменения небольшие, например изменил один конфиг, то проще и быстрей в бэкап скопировать один этот файл.

Точка отказа - это твоя разметка. Сложности с кучей лишних разделов ни к чему.

BTRFS не вариант (прочитал много негативных историй о внезапных поломках фс без возможности восстановления).

Пока собиратели сказок придумывают себе проблемы, рационально мыслящие же люди пользуются достижениями науки и техники.

arch linux, backup, rolling, snapshot

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

BTRFS не вариант

Тогда страдать. Тебе, насколько я понял, не столько бекап нужен, сколько создание точек восстановления, ведь делать резервные копии системных файлов не имеет смысла. В этом случае снепшоты btrfs тебе бы идеально подошли. Перед обновлением делаешь снепшот @latest и создаешь загрузочную опцию, чтобы удобно загрузиться в него в случае проблем после обновления.

Если совсем не хочешь btrfs, то колхозь через rsync или borg. Ну или смотри в сторону воспроизводимого окружения по конфигуранному файлу.

Делаю снимок lvm тома. Далее dd на внешний жесткий диск. Пробовал восстановится в виртуалку, работает. Раздел /boot тоже в lvm. Система ubuntu lts.

Извините, люди, которые на полном серьёзе в 2021-м году рассматривают ext2 (не журналируемую ФС, которая by design разваливается от малейшего дуновения) на основании того, что она «проверенная временем», и на том же основании заведомо отказываются от технологий, специально предназначенных для решения названной задачи — никакой другой реакции не вызывают.

Всего доброго.

Счастливо оставаться, это же не мне надо решить проблему.

Ну и проблемы nix конфигурации по разным программам тоже никто пока не отменял. Может лет через 5 когда более-менее будут допилены конфиги разных прикладных программ в nix, тогда может быть попробую nixos.

Чего конкретно тебе не хватает?

Если ты планируешь бэкапить и восстанавливать всю систему, то это не так чтобы сильно быстро все..

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

Можно подробнее? Мне, как новичку, было бы очень интересно, что с Вами случалось, на что Вы наталкивались в использовании rolling дистрибутивов Linux.

рационально мыслящие же люди пользуются достижениями науки и техники.

Можно подробне? Я просто учусь…

Поправьте, если я все еще не прав.

Я и все знакомые пользуются снапшотами для бекапа примерно так:
* Создаётся снапшот в read only режиме. LV с системой продолжает работать как обычно.
* Снапшот монтируется.
* С него чем-то делается «копия» в другое место. Не обязательно полное копирование, как правило только разница.
* Снапшот отмонтируется.
* Снапшот удаляется.
Снапшот тут нужен для того, чтобы копировать консистентное состояние раздела (LV). Иначе, если делать просто с раздела, пока копируется одна часть файла, другая может продолжать записываться каким-либо приложением, состояние разных файлов будет не согласовано и т.п. А снапшот это моментальный снимок, в том смысле, что все операции приостанавливаются, пока он создаётся. Этого не всегда достаточно. Например, если у тебя есть активно работающая база данных, то с ней нужно особое обращение. Либо её нужно остановить до создания снапшота и запустить сразу после, либо её надо бекапить какими-то специальными средствами. Но для простого домашнего применения вполне достаточно.

Спрашивайте что конкретно Вас интересует.

BTRFS

Подразумевается работа за рабочей станций, а именно - дОмАшНеЙ.

Подскажите, как и зачем мне использовать ЭТО дома?

Как ТС радостно вбрасывает - на rolling дистрибутиве?

Спрошу у вас по поводу снимка lv. Даем команду:

lvcreate -L5G -s -n root-sn /dev/c55/root

Получаем:

/dev/c55/root-sn

Это и есть снимок, и его надо копировать или делать dd?

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

Это и есть снимок, и его надо копировать или делать dd?

Да, это снимок раздела на момент выполнения команды. /dev/c55/root, если он смонтирован, продолжает обновляться.

у вас

Давай на ты. На ЛОРе все братья и сёстры! Линуксоид линуксоиду друг, соратник, надёжная опора... а так же метатель фекалий, тролль и лжец

Благодарствую, сударь.

Для хомяка снимки отличная защита от случайного удаления полезных файлов, например.

Для этого не нужно таких сложностей. Если данные необходимы - backup. Если настройки необходимы (dotfiles) - облако и/или backup. Не понимаю повальное желание всё в github хранить, ИМХО.

Чтобы спасти хомяка и других животных - выделяй разделы. ВСЁ. Конец. Никаких снимков дома не надо. Вам бы навернуть абстракций ради самого процесса.

Когда что-то пошло не так с обновлением для системы или какими-то экспериментами

Как может пойти не так с экспериментами, я не знаю. Мне бы примеры. А то я если что-то совсем странное делаю - chroot спасает пацана.

P.S. Лично тут с Саакриту спорил, кто быстрее бинарный дистр развернёт. Хоть и шуточно, но при подключению к инету - одна команда…

Далее dd на внешний жесткий диск.

При dd пустое место тоже копируется. Не лучше ли rsync или какие-то средства копирования раздела, которые учитывают пустое место, вроде Clonezilla?

rsync

Пока не осилил )). Чтобы быстрее скачивать, делаю zip архив. Он и хранится на внешнем винте. Система из ноута - без архива, там всего 40 гиг.

Чтобы быстрее скачивать, делаю zip архив

Беру первый попавшийся каталог(~250мб), делаю zip-архив. Загружено одно ядро из четырех, сжимает около минуты. Делаю squashfs. Загружены четыре ядра, около 15сек. Размер архива почти одинаковый. Но скваш оптимизирован для произвольного доступа, можно смонтировать.

Делаю squashfs.

Тоже неплохой вариант. Жаль, тут нет возможности эффективно хранить предыдущие состояния.

NixOS

Предыдущие состояния - предыдущий скваш.

То есть можно сделать так?

mksquashfs /dev/c55/root-snapshot-lvm /mnt/root.sq

dd if=/mnt/root.sq of=/dev/c55/root bs=8M

И будет работать?

Держи не бэкап, а средство для воссоздания конфигурации. Это показывает, что именно изменялось в конфигурации, а не только фактическое состояние. Ну и места занимает меньше.

Чтобы спасти хомяка и других животных - выделяй разделы. ВСЁ. Конец. Никаких снимков дома не надо. Вам бы навернуть абстракций ради самого процесса.

Каким макаром спасают разделы от случайного удаления данных?! 🤦‍♂️

Для этого не нужно таких сложностей.

Каких сложностей? Вы действительно считаете снимок чем-то сложным?!

Если данные необходимы - backup.

Я что-то говорил про ненужность бэкапа? Вы смешиваете зелёное с квадратным. Снимок нужен для БЫСТРОГО восстановления, после неудачных действий. Можно элементарно по запаре удалить просто что-то рядом с тем, чего удалить пытался на самом деле - это так, элементарный пример. Человек не робот, может ошибиться. Бекап спасёт, конечно, но он необходим при серьёзном сбое, при смерти носителя как вариант. Откапитить неудачный rm проще и быстрее из снимка. Это разные задачи.

Как может пойти не так с экспериментами, я не знаю. Мне бы примеры. А то я если что-то совсем странное делаю - chroot спасает пацана.

Элементарно какой-нибудь установщик fglrx в былые времена мог поломать всё к чертям. И через chroot это, конечно, чинилось, но из снапшота восстановить корень это один раз mv, выполняющийся доли секунды, а через chroot возня с затратами сил и времени, я уж молчу о том что бывает не так просто и мусор убрать после неудавшегося эксперимента, иной раз проще переустановить дистриб. Вам, может Ваше время не дорого, а моё стоит больших денег. А бывало приходилось делать разное и самосборную mesa внедрять и драйвера для разных железок прикручивать, а с ними и кучу всякого говна. Снапшоты сэкономили мне огромное кол-во времени и денег.

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

А ты еще не сделал? Нет у меня lvm и snapshot, чтобы проверить, слишком сложно. Первая команда создаст /mnt/root.sq. Во второй, если в /mnt/root.sq примонтирован твой скваш, то запишет в «of=». Только посмотри справку по [mk|un]squashfs, там есть свои закоряки, по памяти не подскажу.

используй btrfs только под систему, а файлы, которые боишься потерять (/home) на ext4. У btrfs со снапшотами дела лучше, чем у lvm2

предыдущий скваш.

Это понятно, но это не эффективно, т.к. файлы без изменений всё равно записываются.

Прямо с блочного устройства не хочет. Надо монтировать том, и с него делать mksquash.

От случайного удаления важных файлов лучшая защита - nilfs2. Потому что при ручном создании снапшота, время жизни файла может оказаться между этими самыми снапшотами

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

Да, это я упустил. Спасибо.

ext2

Ололо. Знаешь, при таких раскладах даже Btrfs не выглядит таким уж плохим вариантом.

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

Мы говорим о домашней рабочей станции. Вы не думаете что обозначаете решение несуществующей проблемы?

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