Комментарии 25
Добрый день. Veeam agent не пробовали для этих целей?
Veeam Backup, Proxmox Backup и прочих коммерческих решений для блочных устройств.
Не соглашусь, VBR Community Edition и ProxMox Backup не являются коммерческими решениями. И бекапить Veeam Agent-м можно и просто набор папок (без создания снапшотов FS).
Выгружать можно бекап и по SSH/SCP сразу на свой другой сервер, как вариант. А ротацию и удаление делать уже на сервере-приемнике.
Еще есть вариант поднять свой NextCloud-сервер, через Fuse/WebDAV монтировать его у себя на VPS.
В общем вариантов много, хорошо, что Вы показали свой )
Удачи и всех благ!
Вообще от скрипта вида:
#!/bin/sh
backupdate=`/bin/date "+%Y-%m-%d-%H-%M-%S"`
backupdir="/BACKUPS/ServerConfigs"
secondbackupdir="/data/BACKUPS/ServerConfigs/"
newarchive=${backupdir}/bsd-configs-${backupdate}.tar.bz2
tar -a -cf $newarchive /etc/ /usr/local/etc/ /root/ /CBSD/etc/ /CBSD/jails-fstab/ /CBSD/jails-system/ && cp $newarchive $secondbackupdir
Можно уйти оч далеко - и в Telegram себе отправлять, и почтой с шифрованием и т.д.
Bash/Shell скрипты дают любые вариации и способы, только придумывай. А сейчас еще и GPT4 может в этом здорово помочь )
После того как сломали авторизацию и перестал работать grive, так и не осилил разобраться c google api, спасибо за инструкцию.
привет а кто это пробывал делать ? Получилось?
У вас используется три инструмента для трёх шагов:
rsnapshot для копирования файлов локально и версионирования
rclone для загрузки файлов в облако
mega.sh (странное название) для шифрования и сжатия файлов
Также вы два раза настраиваете Cron.
Итого - с одной стороны решение гибкое, с другой - сложное и хрупкое.
Borg backup объединяет все три этих инструмента, хотя и поддерживает меньше удалённых хранилищ, чем rclone (что можно обойти монтированием хранилища в локальную ФС), при этом проще настраивается и по умолчанию поддерживает дедупликацию (чего у вас нет).
Да вы издеваетесь:
sudo curl https://rclone.org/install.sh | sudo bash
А что, curl не от рута уже не работает?
КДПВ оказывается использует как минимум одна настоящая (ну как, предположительно) компания по восстановлению данных. Яндекс картинками ищется.
У меня tar архивы получаются по полгигабайта. Некоторое время назад были по 1.5 Гб.
Перепроверьте еще папки и файлы что вы архивируете, если вы берете только натройки тогда они должны весить менее 100 Мб, ну у меня примерно так. Возможно вы что-то лишнее берете например /etc/alternatives архивируете, у меня она много весит.
Пытаюсь понять обоснование использования симметричного шифрования через openssl по сравнению с gpg -e -r "recipient" file? Сразу отпадает необходимость держать пароль в clear text (/root/.config/rclone/pwe), достаточно иметь на VPS публичный ключ recipient.
Бэкап без обработки ошибок не может считаться надёжным даже с натяжкой. Как минимум нужно уведомление об ошибке.
Господа, подскажите, пожалуйста, можно ли организовать бэкапы таким образом, чтобы основной файл бэкапа в сжатом виде создавался, условно, раз в месяц, а изменения - в качестве сжатых же бинарных диффов друг от друга по цепочке с проверкой чексумм на каждом этапе (примерно как происходит внутри git, но в бинарном и сжатом виде)? А то мне нужно организовать ротируемые ежедневные бэкапы файла большой однофайловой базы, он хорошо сжимается, ежедневные изменения небольшие, но трафик для отправки бэкапов в облако (кстати, тоже пользуюсь Mega) крайне ограничен.
Veeam Agent, бекап в блочном режиме, Full раз в месяц, инкременты когда хочешь. Файл базы разместить на отдельном блочном устройстве. Инкременты будут мизерными.
Спасибо, посмотрю. А в open source решениях что-нибудь подобное есть?
Veeam Agent без лицензии будет работать в режиме Community Edition (один JOB). Бесплатно, без ограничений по времени. Да, он не OpenSource.
Чисто OpenSource решение мне не попадалось - но в такой задаче (один файл - база данных, нужны инкременты) - сделать это можно только с помощью технологии Change Block Tracking (CBT). Так что искать нужно решение, которое умеет отслеживать CBT таблицу и делать блочный бекап тома (не файловый - а блочный).
Вышеприведённый Borg оперирует файловыми чанками. Возможно, если нарезать помельче, получится что-то похожее.
Все может быть, нужно тестировать )
О, спасибо, если это так, то может сработать. Сейчас буду изучать и тестировать. Главное, чтобы СУБД не слишком сильно меняла расположение данных в файле при работе (переиндексация, реструктуризация, оптимизация etc, кто его знает, что она там творит под капотом). Полагаю, система разбиения данных в Borg примерно такая же, как в BitTorrent?
Я пытался пихать БД в restic, который тоже бьёт файлы на чанки. Но оказалось, что MariaDB любит поменять парочку байтов в разных местах (наверное счётчики-смещения-размеры какие-нибудь), и из-за этого целые чанки считались изменёнными и бэкапились заново, в итоге экономия на дедупликации не особо получилась
О, я как раз сейчас Restic ковыряю, так как он нативно работает и на винде, и на никсах, да и Go ощутимо быстрее питона, на котором написан Borg, предложенный выше. Скормил ему папку с нативными полными бэкапами от самой СУБД за три дня (общий размер 36 ГБ), указал максимальное сжатие, в итоге Restic'овская репа занимает 5 ГБ, что очень неплохо. Но это родительский бэкап, будем смотреть, как он с инкрементами будет справляться. Такую проблему, как у вас, я и предвидел, поэтому сейчас выясняю на тамошнем форуме и в доках, как уменьшить размер чанка до минимума (теоретически должно помочь, если при этом данные не сдвигаются внутри файла). Как-то в итоге удалось решить проблему, или оставили, как есть?
Пока что не стал заморачиваться, какая-то дедупликация всё-таки имеется и хранить в restic всё равно получается компактнее чем без него
На форуме мне ответил один из разрабов Restic. Размер чанка определяется динамически от 512 КБ до 8 МБ, но стремится к примерно 1 МБ, и вручную задавать это значение не получится. Кроме того, я задал вопрос по поводу алгоритма компрессии - там zstd, и поменять его нельзя. Zstd - это неплохо, но удивляет прибитие гвоздями подобных вещей без уровня абстракции.
Менять конфиг системы и добавлять дополнительные блочные устройства (даже виртуальные) у меня нет возможности, так что мимо. Проблема еще в том, что в окружении - мультисистемный зоопарк и таких файлов баз с необходимостью бэкапа несколько, каждый на разных машинах, поэтому искал кроссплатформенное решение. При этом я вручную пробовал тупо диффать два варианта файла (условно, вариант файла в понедельник и измененный вариант в пятницу) rsync'ом и сжимать дифф (операция восстановления в этом случае - разархивация диффа и patch понедельничного файла этим диффом от пятничного), и оно работало - размер сжатого диффа укладывался в приемлемые 100 МБ при размере несжатой базы в 12 ГБ, но решил не велосипедничать со скриптами и поискать что-то готовое, так как опасаюсь при их написании не учесть все corner case'ы и запороть восстановление базы при такой необходимости. Что ж, видимо, всё-таки придется писать свой скрипт, благо, WSL на виндовых машинах есть.
Backup. Файловое резервное копирование бюджетного VPS