LINUX.ORG.RU

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

 , , ,


0

4

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

  • ПК один.

  • В ПК два диска - SSD 256 Гб под систему и рабочие файлы, HDD 500 Гб под файлопомойку и бекап рабочих файлов.

  • У ПК есть доступ в интернет.

  • Всегда есть две флешки, на одной из которых свежий срез роллинг дистра.

  • BTRFS не вариант (прочитал много негативных историй о внезапных поломках фс без возможности восстановления). Хотелось бы оставаться с проверенными временем фсами вроде ext2, ext4.

  • При необходимости системные разделы могу переразбить. Сейчас у меня выделен только /boot/efi, /boot и /.

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

Пока нашел для себя два варианта: 1) быстро переустановить систему из свежего среза, запустить предварительно созданный скрипт для настройки новой системы и восстановить с HDD рабочие файлы, если пришлось форматировать весь SSD; 2) переустроить разделы с помощь LVM и делать снапшоты LVM с ротацией каждый день на рабочей системе, чтобы в случае поломки при обновлении быстро восстановить снапшот.

У первого варианта два минуса - 1) в свежем образе может оказаться такая же проблемная версия программы, которая привела к неработоспособности системы, 2) если сошлись звезды и в момент поломки отсутствует интернет, я не смогу установить нужные программы, значит нужно где-то организовывать локальное хранилище пакетов.

У второго варианта пока вижу один минус - при интенсивной работе с файлами, LVM снапшоты могут сильно разрастить при ежедневных снимках. Хранить, я думаю, нужно минимум 2-3 снапшота, чтобы если один вдруг оказался нерабочим, восстановить из другого.

Поделитесь вашими соображениями. Сразу скажу что не ставлю целью отработать случай поломок железа. Только программные проблемы вроде баганой версии системного софта.

Ответ на: комментарий от erfea

Перечитал и клюнул на вброс:

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

Ну ты и дал. ROFL. Я chroot не для восстановления использую, а для экспериментов. Некоторые эмулируют машины ;))) Ох не могу.

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

У дедушки может не быть члена, и тогда он будет бабушкой. Зачем делать снапшоты не регулярными изначально?

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

Зачем делать снапшоты не регулярными изначально?

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

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

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

Тихо, мы realtime пишем. Это же не прод, это (нежно) - хомяк!..

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

Ну ты и дал. ROFL. Я chroot не для восстановления использую, а для экспериментов. Некоторые эмулируют машины ;))) Ох не могу.

Эксперименты с fglrx в chroot и на виртуалке, ага рабочий рецепт! Спасибо не возьму на вооружение, так как не годится.

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

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

erfea ★★★★★
()

Фатальный просчёт заключается в следующем:

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

Это не так.

Btrfs как раз полезна в части бэкапов за счет snapshot. Я использую btrfs для бэкапа всех разделов несколько лет, всё работает как часы.

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

Какие только проблемы люди не преодолевают лишь бы не использовать нормальные решения. Например, ZFS.

system-root ★★★★★
()
Ответ на: комментарий от Nodokan

Нет, снапшот хранит разницу, но изменения происходят с тем, от кого снимок. Т.е. при записи записи в блок оригинала он сначала считывается, потом это записывается в снимок, тогда уже происходит запись получается на одну запись приходится еще одно чтение и запись. Вроде так. С вложенными снимками скорость падает до неприемлемых уровней. Эту проблему решает LVM Thin Provision.

boowai ★★★★
()
Ответ на: комментарий от system-root

Какие только проблемы люди не преодолевают лишь бы не использовать нормальные решения. Например, ZFS.

Дома? Но зачем? Память zfs люююбит.

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

Дома? Но зачем? Память zfs люююбит.

Я подписан на много технических рассылок (gcc, python + набор связанных библиотек, postgres, grub, lvm и проч), очень часто обсуждается использование на разделах btrfs/zfs, выгоды и проблемы. Вполне нормальные ФС. И только на лоре какой-то школьник решил «всех профи под одну гребёнку» своим невежеством удивить. Ты со своими комментариями выглядишь убого.

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

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

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

На моей рабочей машине снапшоты делаются каждые 5 минут за последние 2 часа, каждые 15 минут за последние 24 часа и каждый час за последнюю неделю. Брат жив, защита от криворукости отличная, выручала несколько раз.

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

Сколько за день — не знаю. Всего —

# compsize /mnt/rootfs/arch
Processed 2883593 files, 1979627 regular extents (2067507 refs), 1559366 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       85%      350G         409G         417G

# df -h /
Файловая система Тип   Размер Использовано  Дост Использовано% Cмонтировано в
/dev/mapper/root btrfs   837G         413G  424G           50% /

Примерно 413 - 350 = 63 GiB.

intelfx ★★★★★
()

а почему не timeshift? у него ж для арча есть пакет,который бекапит только обновляемые файлы. поломались, откатил из бекапа файлы, готово

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

Когда я рассматривал btrfs, писали, что место для снапшотов может кончиться и это похерит вообще всю ФС. Что-то в этом духе. Это и сейчас так?

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

Тогда за сколько это времени накопилось?

Расписание снапшотов я выше привёл. Это за неделю.

Вообще, объём снапшотов btrfs в точности равен суммарному объёму изменений в файлах. Так что решать тебе и только тебе.

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

Значит норм. Надо попробовать накатить арч с бтрфс. Буду делать судо пакман -Суи и если что откатывать снапшотом :)

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

nilfs2

Это интересно. Можете описать опыт эксплуатации nilfs2?

Какие у неё минусы/ограничения?

Как Вы её используете? Какие у Вас особенности конфигурации?

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

Такой проблемой, напротив, страдает LVM.

LVM thin pool, точнее. И то я не уверен, что там именно потеря данных идёт (а не остановка работы).

Обычный lvm весьма надёжен.

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

Какие у неё минусы/ограничения?

Работает медленнее обычных ФС. Все снапшоты, как автоматические при изменении/удалении файлов, так и ручные в качестве названия имеют только номер, задать название как в BTRFS или ZFS нельзя.

Как Вы её используете? Какие у Вас особенности конфигурации?

Просто отформатировал в нее диск с важными файлами, что бы случайно их не потерять. Раньше еще исходники на ней хранил, что бы не потерять изменений между коммитами, но из-за скорости ФС решил отказаться.

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

Я потом посмотрю как вся твоя коллекция ониме исчеснет из-за бага в btrfs, и ты будешь её долго и мучительно восстанавливать (если конечно вообще восстановится). И кто после этого ССЗБ?

Алексей

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

Я потом посмотрю

Ну посмотри.

как вся твоя коллекция ониме исчеснет из-за бага в btrfs

Она может исчезнуть из-за бага где угодно, в том числе из-за бага в железе. Если у данных нет бэкапа, то эти данные недостаточно важны. Я придерживаюсь этого принципа и всем советую.

И кто после этого ССЗБ?

Тот, кто не продумывает модель хранения, адекватную потребностям.

intelfx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.