Введение

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

Примерно так выглядит переключение между снапшотами
Примерно так выглядит переключение между снапшотами

Проблема стабильности

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

Snapper как решение

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

  • Создает дельта-копии системы (только измененные файлы)

  • Автоматически делает снапшоты при обновлении пакетов

  • Позволяет делать ручные снапшоты в важные моменты

  • Занимает минимум места благодаря умной системе хранения изменений

  • Легко откатывает систему к любому сохраненному состоянию через меню GRUB

Требования и установка

Главное требование для работы Snapper - файловая система BTRFS. По моему опыту за последние полгода использования на разных дистрибутивах, BTRFS работает стабильно и не создает проблем с производительностью.

:)
:)

Snapper предустановлен в некоторых дистрибутивах:

  • openSUSE (один из самых недооцененных дистрибутивов, к слову)

  • Spiral Linux (основан на Debian, но оптимизирован для работы), на котором сижу сейчас

Личный опыт

За последнее время Snapper спас мою систему как минимум 5 раз в критических ситуациях. Например:

  • При проблемах с установкой DeepSeek Coder и Ollama (когда скрипт установки Ollama некорректно обновил драйверы NVIDIA)

  • В различных ситуациях с конфликтами пакетов

  • Когда пытаешься что-то поменять в системе под себя

Восстановление происходит элементарно: загружаетесь через GRUB в раздел Advanced options, выбираете нужный снапшот по дате и описанию - и система возвращается в рабочее состояние.

Заключение

В консоли
В консоли

После множества экспериментов с разными дистрибутивами Linux, я пришел к выводу, что Snapper - это must-have инструмент для любого пользователя Linux. Это не просто система бэкапов, а встроенный механизм защиты, который позволяет в любой момент восстановить работоспособность системы буквально в пару кликов.

Рекомендую настроить Snapper сразу при установке системы - это может сэкономить вам часы или даже дни восстановления после серьезных сбоев.

Если вам есть что сказать, пожалуйста, напишите в комментариях, мне и другим это будет полезно :)

Комментарии (30)


  1. GerrAlt
    03.01.2025 10:38

    Попробуйте NixOS - вам не придется думать о снапшетах системы т.к. вся ваша система будет деклоративно описана и при обновлениях у вас в grub остаётся предыдущая версия системы, которая загрузится ровно так как это происходило до обновления. Это еще не говоря о всяких nix-shell, позволяющих выполнить установку пакетов в работающую систему, но так что если вам что-то не понравилось, или что-то поломалась вы просто перезагружаете систему и она работает так, как будто установки вообще не было.


    1. MountainGoat
      03.01.2025 10:38

      Для этого совершенно не нужно связываться с левым NixOops, у Fedora Silverblue всё то же самое можно.


      1. GerrAlt
        03.01.2025 10:38

        к сожалению не знаком с термином "NixOops", гугл не помог, не могли бы развернуть мысль, что не так с NixOS? Интересуюсь вопросом т.к. далеко не первый дистрибутив и пока что (1.5 года) от него строго положительные ощущения, хотел бы быть готовым к неожиданностям


        1. MountainGoat
          03.01.2025 10:38

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


  1. polearnik
    03.01.2025 10:38

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

    ПОэтому я пока на ext4 но скучаю по мгновенным бэкапам системы.


    1. Kurnevsky
      03.01.2025 10:38

      В некотором смысле btrfs надежнее, чем ext4. В ext4 нет никакой защиты от silent data corruption. С btrfs как минимум будет известно, что данные повреждены.


      1. MountainGoat
        03.01.2025 10:38

        Вы сначала придумайте условия, где на обычном домашнем ПК или простом сервере можно этот мифический silent data corruption получить.


        1. aborouhin
          03.01.2025 10:38

          Не скажу за случайное повреждение в ходе нормальной работы (космические лучи и вот это всё), но после сбоев в работе системы zfs scrub находил и исправлял ошибки неоднократно. В отсутствие механизмов контроля целостности файлов на уровне ФС это была бы как минимум потеря данных.


          1. MountainGoat
            03.01.2025 10:38

            Речь о ZFS рейде? это другой разговор.

            Но выше речь шла о сравнении с ext4 который рейды не умеет. На одиночном диске scrub операция только высветит вам сбойные файлы, тогда как на ext4 то же самое можно достичь через что-то банальное вроде `find * -exec cp {} /dev/null` разве что чуть помедленнее.


            1. aborouhin
              03.01.2025 10:38

              Без рейда даже не рассматриваю, уж сервер-то точно. ext4 может быть поверх аппаратного рейда, lvm или mdadm, в сравнении с этими вариантами zfs/btrfs как раз и выигрывает, т.к. "знает" из коробки, какие данные целые, а какие битые. Ну есть ещё dm-integrity, но не разбирался, не пробовал, не скажу...

              А btrfs/zfs на одиночный диск - только ради снэпшотов, возможно, если они прямо очень нужны. Но они и в lvm есть.


      1. Parmenides
        03.01.2025 10:38

        Ни разу не терял данные на ext4, а вот на btrfs это случалось 4 раза (причём из них 2 раза - все данные вообще в кашу), больше не хочу.


  1. 0mogol0
    03.01.2025 10:38

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

    Вопрос, я правильно понимаю, что snap'ы хранятся локально и в первую очередь являются аналогом "точек восстановления" Windows? или их можно делать на внешнем / удалённом носителе, чтобы потом восстановить систему с нуля?


    1. aborouhin
      03.01.2025 10:38

      Насколько я понимаю, в BTRFS есть такой же механизм send/receive, как и в ZFS, так что если на сервере для бекапов поднять ту же файловую систему, то можно каждый снэпшот передавать по сети на него.

      Я всё описанное в статье плюс удалённые бекапы делаю на ZFS штатными средствами, только что интеграции с Grub нет, так что откат к предыдущей версии, если что, придётся делать ручками через initramfs.


    1. RTFM13
      03.01.2025 10:38

      Для бэкапов именно системы есть timeshift. Можно и пользовательские данные туда включить, но не рекомендуется. И флэшка с лайв-системой понадобится (это вообще полезно иметь).


  1. NutsUnderline
    03.01.2025 10:38

    BTRFS здорового человека? выглядит интересно.

    я отошел от BTRFS как раз после вылета, причем именно этой самой BTRFS

    и особые моменты были когда так или иначе ломался grub. как раз для этого приходиться доставать телефон и вбивать в командную строку grub. я нашел super grub disk который позволял грузиться в рабочую систему с убитым grub и восстановить его нативным образом. но super grub disk не учитывал тонкости в виде субтомов BTRFS и пришлось модифицировать его.