Нубу нужны рекомендации по организации бекапов

Bacula какая-нибудь?

borg умеет по ssh бекапить. На принимающей стороне запускается borg-server, который принимает команды и данные. Надо только в ~/.ssh на сервере конфиг с ключами сделать, а на принимающем компе открытый ключ в authorized_keys добавить.

Я так с удалённого сервера на домашний комп бекап настроил. Если интересно, могу расписать, как и что делал.

В твоей системе нет timeshift?..

borg для серверов

borg + vorta (gui) для десктопа.

Все эти хотелки прекрасно покрываются как раз borg. Не знаю, что там за дичь, тем более непонятная. Я бы советовал всё же ещё раз попытаться покурить маны и вникнуть. Ещё проще так-то некуда.

Там скорее всего с «borg serve» непонятки возникли.

Вот статья, которая меня смутила: https://borgbackup.readthedocs.io/en/stable/deployment/pull-backup.html

Это не то, что мне нужно?

Ключи ssh уже настроены. Единственное - это у меня нестандартные порты для подключения по ssh. Если не трудно, то напишите, пожалуйста, как у вас это устроено.

А говоришь маны. man borg.

Статью не читал и не горю желанием.

Делай бэкапы на второй раздел того же диска.

https://siberoloji.com/how-to-configure-automatic-backups-with-rsnapshot-in-debian-12-bookworm/

https://wiki.debian.org/BackupAndRecovery

нестандартные порты для подключения по ssh

На хосте, откуда будет производиться бекап.

# .ssh/config
Host backup-server
        Hostname hostname.tld
        Port 12345
        User backup-user
        ForwardX11 no
        Compression yes
        IdentityFile ~/.ssh/borg_backup.key
        ServerAliveInterval 10
        ServerAliveCountMax 30

По названиям параметров разберешься.

На хосте, куда будет производиться бекап.

/home/backup-user/.ssh/authorized_keys
command="borg serve --restrict-to-path /path/to/backup",restrict ssh-ed25519 открытый_ключ комментарий

У юзера должен быть нормальный shell, чтобы команды запускать.

А дальше можно делать всё точно так же, как и с локальными бекапами, только в адрес репозитория добавляешь backup-server:/path/to/backup

Я делал скрипт со всеми командами, таймер на запуск по расписанию и юнит, который этот скрипт дёргает.

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

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

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

Это официальная документация borg, если что, а не васянская графомания.

Спасибо, буду пытаться понять как это работает.

Собственно из документации и брал

https://borgbackup.readthedocs.io/en/stable/usage/serve.html

(+ Radjah)

Я понял, что официальная. Но было сказано «маны», из чего я сперва решил, что имеется в виду буквально man borg. И что характерно, для реализации перечисленных хотелок его достаточно.

Мне больше restic приглянулся. Они похожими кажутся при беглом взгляде на доки borg’a. Не?

Да и rsnapshot при беглом взгляде кажется, что похож на borg и restic, поэтому лично мне сложно выбрать что-то одно.

Мне больше restic приглянулся. Они похожими кажутся при беглом взгляде на доки borg’a. Не?

Только restic на golang написан. И если я ничего не пропустил, он не умеет делать репозитории без пароля, и по компрессии данных у него выбор бедный был. Но при этом его можно без проблем использовать на Windows. borg у меня там запустить не получилось. Может уже и сделали, я давно не проверял.

А ещё он умеет сразу в облака бэкапить через rclone.

Только restic на golang написан.

А надо на ассемблере?

Недавно озадачился вопросом организации бекапов для моей домашней пекарни, медиа-сервера и VPS-ки.

Думайте не только лишь об организации резервных копий, но и о восстановлении файлов из ваших резервных копий.

Bacula/Bareos совсем не noob-friendly :)

Мне больше restic приглянулся.

Вот мне тоже. restic и rest-server понравились, внедрил.

я люблю инкрементальные бэкапы с помощью duplicity .

Сжатие:

Borg: Поддерживает различные алгоритмы сжатия данных, что позволяет уменьшить размер резервных копий.
Restic: На данный момент не имеет встроенной поддержки сжатия. 

Управление и гибкость:

Borg: Операции очистки (pruning) выполняются быстро и эффективно.
Restic: Операции очистки могут занимать много времени и требовать больше оперативной памяти. 

Какую-то компрессию умеет https://restic.readthedocs.io/en/latest/047_tuning_backup_parameters.html#com...

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

Напомните, как borg’ом делать offline бекапы.

Кажися borg mount умеет в чтение архивов. Нужно почитать как делаются эти архивы.

Restic: На данный момент не имеет встроенной поддержки сжатия.

Уже умеет, 3 года как: https://restic.net/blog/2022-08-25/restic-0.14.0-released/

Нубу нужны рекомендации по организации бекапов

Обязательно делайте.
Вот с год ленился сделать бэкап внешнего винта и всё потерял.
К счастью, что касаемо разработки всегда минимум две копии.

Скажу вам по секрету - «Один раз в год и палка стреляет».

Человек не разобрался с borg, с бакулой разберётся в три счёта, ага.

Есть такой дистр, название ему Parted Magic на основе Gparted и других.Он может со слов разработчиков клонировать диск и делать резерв.Я лично им не пользовался, так как особо необходимости нет.Скачать можно с рутрекера, но это особо законно.А так он выдается по подписке.Удачи! P.S. Он похож по функциям с Acornis

А я borgmatic пользуюсь. Один раз конфиг сляпал и айда. И команды простые. Нраица.

Что за offline-бекапы? o_0

Просто в каталог делаю так:

#backup
/usr/bin/borg create --stats --compression zstd,11 --umask 0007 /data/Backup/Data/matrix::matrix-{now} /var/lib/matrix-synapse

#clean
/usr/bin/borg prune --keep-last 15 --stats --umask 0007 /data/Backup/Data/matrix

#compact
/usr/bin/borg -v compact --umask 0007 /data/Backup/Data/matrix

Создать новый бекап со сжатием в zstd и именем «matrix-текущая дата и время»

Удалить старые бекапы, кроме последних 15 штук.

Удалить неиспользуемые данные из репозитория.

cron bash и rsync :)

примерно такой командой:

rsync -av –delete –exclude=~* –link-dest=$BACKUP_DIR/latest $MOUNT_DIR/ $BACKUP_DIR/$A_DATE/

инкремент за счет хард линков и делай хоть пару раз на день

Что за offline-бекапы?

Бекапы, которые вообще не подключены ни к какой электронике. Подключили флешку (или НЖМД через адаптер, коих полно, или вставили кассету в ленточный накопитель), скомандовали «сложи бекап сюда», отключили флешку, положили в сейф.

На следющий день подключили другую флешку, сделали бекап, положили в другой сейф. И так несколько раз.

Через полгода достали одну из флешек, и восстановили с неё данные.

Офлайновые бекапы нужны чтобы взломщик не мог удалить или испортить ваши резервные копии. Если бекапы, например, заливаются на NAS, который всегда подключен по сети, то злоумышленник, который получил контроль над ЭВМ, сможет их, например, зашифровать. И вроде бы у вас бэкапы были, а толку от них никакого.

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

А вот если я borg’у дам командоньку «восстанови мне файл /home/user/Documents/account.txt в том виде в котором он был 12 февраля в 12:00», то borg мне скажет «подключи флешку Volume12, там лежит ближайший бекап этого файла, 14 февраля 23:12»? Или я сам должен буду найти на которой из флешек у меня лежит бекап за нужную дату?

Только restic на golang написан.

Есть borg2, он тоже на golang

Или я сам должен буду найти на которой из флешек у меня лежит бекап за нужную дату?

Сам

Плёхо.

Значит Bacul’е/Bareos’у всё ещё нет альтернатив для нормального бекапа.

А почему бы не использовать различные методы для бэкапа, а не быть привязанным к одному приложению?

Делай бэкапы на второй раздел того же диска.

Это медленно, надо в /tmp

Тогда сразу в /dev/null.

Тогда сразу в /dev/null.

Оттуда одни нули читаются

Нули из /dev/zero читаются, а достать бэкап после записи в /dev/null с некоторой вероятностью можно из /dev/random или /dev/urandom.

можно из /dev/random или /dev/urandom.

там памяти море, и все время новая )

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

Настройка borgmatic для домашнего ПК ожидаемо не вызвала никаких проблем. А вот с VPS пришлось поломать мозги и потратить кучу времени.

Во-первых, пришлось отказаться от первоначального плана не использовать ssh-подключение к моему ПК. Пришлось поднимать устойчивый реверс-ssh-туннель со стороны ПК с помощью systemd-юнита.

Во-вторых, пришлось заморочиться с базовой безопасностью, чтобы в ключе авторизации по ssh был доступ только одной команде - «borg serve –restrict-to-path /run/media/bernd/backups» и к одному ограниченному пользователю, которого я создал специально под это дело, а также с другими ограничениями (no-agent-forwarding, no-pty, no-user-rc).

В-третьих, на моем ПК стоит Arch, а на VPS - Debian, поэтому версии borgmatic сильно отличались, а значит и синтаксис файлов конфигураций. Это тоже было больно. Но в итоге спёр у кого-то на гитхабе конфиг старого borgmatic и оно заработало.

Восстановление полностью протестировал разными способами, там всё довольно просто. Самое простое - это смонтировать архив с бекапом и там уже смотреть какой файл тебе нужен.

Теперь осталось только настроить borgmatic на бекапирование баз данных и настроить автоматизацию создания бекапов (cron или таймеры systemd, пока еще не выбрал что лучше).

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

чтобы если какой-то из бекапов не смог создаться, то мне в телегу приходило сообщение (наверное, с помощью grafana)

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

Если нет - можешь написать простой rest api через python / go / bash скрипт (curl), думаю хуки / события либо поддерживает сам borg, либо можно так же в cron / timer вписать команду проверка и отправку через curl, например, сообщения в ТГ.