А что есть по бэкапам?

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

borg, restic.

Restic

urbackup? Там ещё дедупликацию завезли на файловом уровне. И сжатие можно включить. В общем не скучно.

Основная хотелка такая: во время когда пекич нагружен сильно, бэкап не сжимается, а только делается, тот же сырой tar без пожатия. Потом когда мне удобно, я жму кнопку и оно всё запаковывается получше/сбрасываются лишние промежуточные этапы.

А потом ты забываешь недельку жать кнопку и вот.

И это, ниче, что пожать каким-нибудь lz4 и отправить в сеть сейчас подчас легче, чем на диск сохранить?

Так что btrfs send | lz4 | ssh backup_host 'lz4 -d | btrfs receive', ну или хотя бы tar c | lz4 | ssh backup_host lz4 -d | xz -9 > timestamped_file'.

Дедупликация на файловом уровне в 2020 — это просто пушка.

Backupninja можно как вручную тыкать, так и автоматически запускать.

Попробуй man gpgtar

reflink же - да, это в целом новая штука.

Это была ирония. У белых людей дедупликация исключительно блочная. Файловая это смешно.

А потом ты забываешь недельку жать кнопку и вот.

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

Backup-ы делаю с помощью btrfs+rsync, получается always incremental backup:
- при первом backup-е естественно копируется всё;
- при очередном копировании делаем rw snapshot с предыдущего (самого последнего) snapshot-а - получаем как бы моментальную копию файлов «за вчера», которую можно править. Предыдущий snapshot при этом readonly, он не изменяется;
- rsync-ом подтягиваем копию «за вчера» до состояния «на сейчас»;
- переключаем в readonly;
- выполняем удаление старых snapshot-ов, вышедших за рамки периода/количества хранимых backup-ов.

Плюсы:
- место на диске потребляется только под изменения частей файлов. Если какие-то части или целые файлы не изменялись, они хранятся в единственном экземпляре, хоть и присутствуют в куче snapshot-ов;
- snapshot-ы не зависят друг от друга, они работают примерно как жёсткие ссылки, только более независимые. Можно удалять какие угодно и когда угодно, на остальные это не повлияет;
- snapshot-ы находятся в readonly режиме - исключается возможность случайно что-то в них повредить (даже root-у);
- все файлы хранятся как есть, а не в контейнере типа tar, backula/bareos - их максимально легко достать из backup-а. Есть возможность сделать grep/diff по всем backup-ам и проследить в какой момент тот или иной файл изменился;
- каждый snapshot - это конечный целостный набор файлов, при восстановлении нет надобности сначала разворачивать full или diff копию, а потом накатывать инкременты;
- ФС поддерживает хранение acl, xattr, т.е. при backup-е (rsync --numeric-owner) ничего не потеряется;
- ФС поддерживает сжатие и увеличение размера;
- копирование через rsync не требует наличия дополнительного свободного места на backup-ируемой машине и не нагружает её сжатием архива. Также ему можно указать выполнение pre/post-скриптов, например, для создания дампов баз.

Минусы: пока не обнаружены.

Такое умеют файловые системы btrfs и zfs.

Такое же умеют restic и borg, при этом не зависят от ФС, и ты можешь спокойно загрузить репозиторий в облако (если не выключил шифрование).

snapshot-ы

не требует наличия дополнительного свободного места

Продолжай наблюдение.

restic или borg, но у первого нет сжатия

Пока файл не изменился, дополнительного места его снапшот действительно не занимает.

btrfs

rsync

snapshot

Я конечно не эксперт по btrfs, но…

Зачем нужен тормоз rsync? Почему send/recive?

Продолжай наблюдение.

Вы не поняли, snapshot делается на машине backup-ов - КУДА копируем данные, а про место я писал на машине ОТКУДА делаем.
Туда, ОТКУДА делаем, мы приходим только забирать данные, ничего локально там не создаём.

snapshot делается на машине backup-ов

Оригинал не снапшотится и бекапятся грязные (изменяющиеся) данные?

Зачем нужен тормоз rsync? Почему send/recive?

Потому что для send/receive нам нужно наличие btrfs/zfs на обоих машинах. На обычных серверах таких ФС нет (приходит на поддержку сервер с только ext4, нужно сделать backup), неоткуда делать send.
А ещё send/receive не работает на уровне каталогов и файлов, только на уровне целых subvolume, а в subvolume может быть много лишнего (например, часто изменяющийся cache), которое мы хотим исключить.

Оригинал не снапшотится и бекапятся грязные (изменяющиеся) данные?

Да. На серверах, где важен моментальный снимок, и подход будет другой, там будет или ФС соответствующая, или LVM, ...

Если вы считаете такой вариант неприемлемым, тогда почти все системы backup-ов (bacula, bareos, ...) - это мусор, ибо они именно так и работают, на уровне изменяющихся «грязных» файлов.

Минусы

Если btrfs развалится (сама или из-за аппаратных проблем) весь бекап тютю.

Я считаю, что создание локальной копии (снапшота оригинала) с последующей отсылкой на бекап-сервер более правильно, чем торможение на неопределенное время rsync через сеть, посредством еще одного тормоза ssh.

Твой метод более-менее рабочий только для единственных файлов и очень маленьких каталогов.

Если любая ФС развалится (сама или из-за аппаратных проблем)… Ну ты понел :)

Нет. Другие ФС проще починить, а также можно достать данные при помощи testdisk или иногда даже grep.

Да. Их не надо чинить. Если проверка репозитория выявила повреждения, то ты просто восстанавливаешь всё из другого бэкапа. Тем более не нужно доставать данные.

Нет. Другие ФС проще починить, а также можно достать данные при помощи testdisk или иногда даже grep.

Вы вот сейчас серьезно о чем? Топик вроде про бэкапы. Или вы предлагаете бэкапы с помощью testdisk и grep выковыривать?
Возможно не понял вашего посыла, тогда извините.

ЗЫ Старое доброе, лучше которого не придумали. Большая периодичность full и с меньшей периодичностью к нему diff или inc от ситуации и реализации зависит. Но в любом случае full делаем регулярно.

Я уже запутался в ирониях, но блочная для бекапов, в общем случае глупая затея. В частном, если поднять отдельный инстанс urbackup, то прикрутить можно и такое. :)

ключевые слова: duply, cron, nice, ionice

блочная для бекапов, в общем случае глупая затея

Очень странное заявление, наверное дураки используют borg в продакшене :) Храню в нём ежедневные дампы БД за несколько месяцев:

------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               12.59 TB              2.11 TB             57.54 GB

                       Unique chunks         Total chunks
Chunk index:                  187245              4795354

Kak tebe takoe, Elon Musk?

https://www.borgbackup.org/ </thread>

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

Не, никакой сети. Вообще.

нет сети — нет бэкапа

Это не скриптик, это схематичный набросок пары идей, которые ТСа миновали: диффы надо снимать эффективно, жать слегка по пропускной способности и слать по сети. Какие из них позаимствовать — решать ему.

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

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

Почему? Подключаешь внешний диск на время бэкапа, потом отключаешь.

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

Основная хотелка такая: во время когда пекич нагружен сильно, бэкап не сжимается, а только делается, тот же сырой tar без пожатия. Потом когда мне удобно, я жму кнопку и оно всё запаковывается получше/сбрасываются лишние промежуточные этапы.

btrfs snapshots + borg. Всё, что ты хочешь, но придётся много велосипедить.

У меня были точно такие же хотелки и я уже навелосипедил: https://github.com/intelfx/backup.sh (если ты реально соберёшься пользоваться этим говном, скажи, я причешу и напишу README). Рано или поздно перепишу на питоне и запилю гуй, но не сейчас.

Я не говорил, что это должна быть единственная копия. 3-2-1, ну.

Не слушайте этих рекламщиков с их Btrfs и сетевыми «бэкапами», которые как игры от EA – не работают без интернета. Rsync+tar+таймер в systemd/«джоб» в cron. Всё остальное (инкременты, распределение нагрузки и прочее) – «портянкой» на «баше». Просто, доступно, понятно любому «линуксоиду».

«линуксоиду»

Редчайший случай, когда твоё болезненное злоупотребление кавычками уместно. Но вообще учи русский.

xfsdump </thread>

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

Не слушайте этих рекламщиков с их Btrfs и сетевыми «бэкапами», которые как игры от EA – не работают без интернета.

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

А что есть по бэкапам? (комментарий) ну.

Бекапы БД, пожалуй единственный случай для которого подходит дедупликация. Но, и без дедупликации уже сто лет в обед придумали инкремент и дифф бекапы для СУБД.

skillz demonstration же! не? ну типа моя вайфу круче вашего.

нет сети — нет бэкапа

вы меня извините конечно, но…лолшто? на проде я могу КАК_ТО в это поверить, но в хоум системах - это ересь.