Just backup btrfs

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

    А вот появилось обновление — два новеньких SSD, было решено во время переноса системы заодно перейти на btrfs.
    Всё отлично — RAID0 для данных RAID1 для метаданных средствами файловой системы, сжатие на лету, корень в одном суб-томе (subvolume), домашняя папка в другом, веб-сайты в третьем. Всё это грузится прямо с UEFI в Linux EFI stub без GRUB и других загрузчиков, работает быстро и удобно.
    И вот дошло дело до снимков (snapshot), их я хотел использовать для резервных копий суб-томов средствами всё того же драйвера btrfs.

    Поиск выдает несколько релевантных решений, но одни решения слишком громоздки (синхронизация резервных копий, через сеть, создание каких-то репозиториев, вложенных потоков и т.д.) и навязывают свою архитектуру, другие не имеют адекватной ротации резервных копий (можно указать только один интервал и количество копий в нём).

    Решение принято — новому инструменту быть!

    И что получилось?


    Получился небольшой скрипт на PHP, который при запуске читает конфигурацию из простого JSON файла вида:

    [
        {
            "source_mounted_volume"         : "/",
            "destination_within_partition"  : "/backup/root",
            "date_format"                   : "Y-m-d_H:i:s",
            "keep_snapshots"                : {
                "hour"    : 60,
                "day"     : 24,
                "month"   : 30,
                "year"    : 48
            }
        },
        {
            "source_mounted_volume"         : "/home",
            "destination_within_partition"  : "/backup/home",
            "date_format"                   : "Y-m-d_H:i:s",
            "keep_snapshots"                : {
                "hour"    : 120,
                "day"     : 48,
                "month"   : 60,
                "year"    : 96
            }
        }
    ]
    

    И создает по указанному пути снимок, а так же при повторном запуске контролирует количество снимков, удаляя устаревшие.

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

    Так как btrfs поддерживает CoW (Copy on Write), то место занятое снимком определяется количеством и объемом измененных файлов с последнего снимка. При удалении снимка все файлы, которые есть только в нем, и больше нигде удаляются, освобождая свободное пространство.

    Итого имеем мгновенный доступ к любому снимку и экономию занятого пространства (что вдвойне правда при наличии сжатия файловой системы).

    Планы


    Добавить сбрасывание последнего снимка (инкрементально) дополнительно на другой btrfs раздел, иначе получается не совсем резервное копирование, а просто машина времени.

    Нужно будет добавить в readme настройку создания снимков перед установкой/удалением/обновлением пакетов (тут уже будет нужна помощь сообщества, так как пользуюсь Ubuntu, и не в курсе как сделать такое для систем с RPM или чем-то более экзотичным).

    Хорошо было бы создать deb/rpm/? пакеты для популярных (и не очень) дистрибутивов, но раньше этого делать не приходилось, не в курсе что да как.

    Возможно что-то ещё подскажете:)

    Где взять


    https://github.com/nazar-pc/just-backup-btrfs

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

    Only registered users can participate in poll. Log in, please.

    А вы используете btrfs?

    Share post

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 25

      +2
      С Btrfs нужно быть аккуратным. В ядро 3.16 (или 3.17) прилетел баг, из-за которого система падает в кернел паник при использовании сжатия. Так-же бывает ФС ломается после нескольких хард выключений подряд. Ломается до не восстановимого состояния. Один раз было такое- в нормально работающей системе корень вдруг перемонтировался в РО, после перезагрузки ФС была сломана, восстановлению не подлежала.
      Да, все вышесказанное приключилось со мной на Arch Linux, ядра всегда последние. Так что если и использовать в проде BTRFS, то я порекомендовал бы какую нибудь убунту 14.04 (т.к. имеет свежее, но достаточно стабильное ядро), ОБЯЗАТЕЛЬНО иметь бэкап и не забывать, что данная ФС может похерить ваши данные.
      З.Ы. В последних ядрах нет изменений BTRFS, кто нибудь знает продолжает ли Oracle разработку, или она заглохла?
        0
        Судя по тому, что я читал на Phoronix изменения есть, почти допилили RAID5/6, падение у меня было года два назад, когда ещё не было стабильного btrfs-progs с ремонтом файловой системы, но найденная где-то git версия файлы вытащила. А за последний год сколько как не выключал — ни одного сбоя, использую rc версии ядер, те что в репозиториях давно не использую. К тому же facebook и google используют уже btrfs в продакшене, некоторые дистрибутивы переключились по умолчанию, некоторые готовятся. Теперь многое в драйвере вместо пачки софта и рпзных конфигов.
          0
          Я же не говорю, что нельзя использвать в проде, я говорю, что можно, но с головой. ;)
          Фейсбук пока начал только тестовое использование. Про гугл ничего быстро не нагуглилось.
          Восстановление BTRFS это песня. Есть там ошибка, что то вроде «error read chunk root» при которой утилиты восстановления ничего не видят и не восстанавливают. У меня она ломалась несколько раз и каждый раз с этой ошибкой.
          История с РО разделом произшла на 3.16-3.17, не исключено, что виновато было включенное сжатие.
            +2
            В 3.17 был баг который рушил всё при создании read-only снапшота (исправили в 3.17.2).
              0
              Спасибо. Я как раз использовал РО снапшоты.
            +1
            Быстрый взгляд на Google Container Engine показывает что там aufs:
            $ sudo docker info
            Containers: 2
            Images: 15
            Storage Driver: aufs
             Root Dir: /var/lib/docker/aufs
             Dirs: 19
            Execution Driver: native-0.2
            Kernel Version: 3.16.0-0.bpo.2-amd64
            Operating System: Debian GNU/Linux 7 (wheezy)
            WARNING: No memory limit support
            WARNING: No swap limit support
            


            Где там у гугла btfs в продакшене? CoreOS поверх GCE не в счет.
              0
              Я смотрел несколько выступлений с конференций, говорили что у них контейнеры в виртуалках в контейнерах, и btrfs используют. В каких сервисах не помню либо не говорили.
                0
                aufs — виртуальная файловая система, которая работает с каталогами, а не блочными устройствами. Вопрос в том, что лежит под ней.

                Впрочем лично я не знаю, есть ли там btrfs.
                  0
                  Я имел в виду, что docker — это чуть ли не единственный кейс в продакшене где использование btrfs реально чем-то оправдано, и даже там он не используется.

                  Aufs поверх ext4 смонтирован, да, но не суть.
                    0
                    То есть btrfs начали разрабатывать за несколько лет до появления docker, а там он оказался не нужен? И Oracle теперь просто по привычке тратит деньги на оплату труда тех, кто разрабатывает btrfs? Мне кажется, что не стоит говорить за всех.

                    Как вариант, могу сказать что ФС со сжатием может использоваться, например, под хранение Whisper базы от Graphite.
                      0
                      Нет, я не это имел в виду :-)

                      Мне самому btrfs очень нравится, но я могу по пальцам одной руки пересчитать приложения, где функциональность btrfs значительно улучшает работу относительно других ФС. Собственно: docker и ceph. Естественно, в силу других механизмов работы, преимущества могут быть и для остальных приложений.
                +1
                > Теперь многое в драйвере вместо пачки софта и рпзных конфигов.

                Это как бы не юниксвейно.
                  0
                  А вы посмотрите на ядро Linux в целом, на systemd и скажите юниксвейно всё это или уже давно нет?
                    +1
                    Про ядро я бы поспорил, правда нет никакого желания, но как бы там ни было, это не повод отказываться от юниксвея и весь остальной софт пилить как Б-г на душу положит…
                  0
                  К тому же facebook и google используют уже btrfs в продакшене,

                  Ссылку в студию, особенно про гугль, ибо у них был ext2, им понравился xfs, но угадайте почему они перешли на ext4…
                    0
                    Вот нашел про Google, но слайды презентации почему-то больше не доступны: www.phoronix.com/scan.php?page=news_item&px=MTc2Njk
                    This week at LinuxCon North America in Chicago is a presentation by Google's Marc Merlin that's entitled «Why you should consider using btrfs, real COW snapshots and file level incremental server OS upgrades like Google does.» The presentation does a good job at looking at the state of Btrfs on Linux and comparing it to ZFS.
              0
              Из расширеных возможностей использую только subvolume. На нем делал загрузку Gentoo или Debian :-).
              Планирую использовать snapshot для тестирования инсталятора, но пока руки не дошли.
                +1
                хранить бакапы на той же ФС как-то небезопасно: если ФС развалится, то снапшоты — тоже

                я бы все таки делал на другое устройство хотя бы тем же rsnapshot
                — он умеет делать хардлинки и одинаковые файлы в разных бакапах не будут занимать лишнего места
                  0
                  Тут скорее бекап от случайного удаления или поломки системы после установки обновлений, если такое случится. В одно мгновение можно загрузиться в то состояние, когда всё работало, можно поэкспериментировать не боясь сломать ОС.
                  А так да, можно даже diff-ы делать между снимками, и хранить инкрементально на отдельном диске/отдельной машине.
                  0
                  Я btrfs использую примерно два года. В домашнем применении — никаких нареканий. Попытка внедрить в продакшен через несколько месяцев (на 3.8) привела к коррапту метаданных самой btrfs, причём btrfsck недоволен, но ничего сделать не может. Коррапченный том вызывает трейсы и зависания ядра.

                  Надо сказать, это был единичный случай, остальные инсталляции живут. Но осадочек остался.

                  Трейс, если кому интересно: bugs.launchpad.net/ubuntu/+source/linux/+bug/1390464
                    0
                    Я тоже пользовался btrfs в домашнем применении. До этого игрался в виртуалке, пытаясь убить резетами. В виртуалке не получилось. А вот когда поставил на реальное железо, SATA шнур, которые физически отходил, довольно хорошо справился с этой задачей. Пришлось вернуться на родную, спокойную ext4
                      0
                      По крайней мере при создании с опциями, отличными от таковых по умолчанию, btrfs может физически вывести SSD из строя.

                      bugzilla.kernel.org/show_bug.cgi?id=85581

                      P.S. Готовый образ btrfs, на котором воспроизводится проблема, до сих пор скачал только один гуглобот и начал качать один пользователь Mac OS X.

                      Only users with full accounts can post comments. Log in, please.