После года разработки представлен выпуск системы резервного копирования restic 0.13, предоставляющей инструментарий для сохранения резервных копий в версионированном репозитории, который может размещаться на внешних серверах и в облачных хранилищах. Данные хранятся в зашифрованном виде. Возможно определение гибких правил для включения и исключения файлов и каталогов при создании резервной копии. Поддерживается работа в Linux, macOS, Windows, FreeBSD и OpenBSD. Код проекта написан на языке Go и распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56924
Гораздо быстрее borg backup но до сих пор не поддерживает компрессию. Поэтому в некоторых случаях размер на диске неприемлим для использования как полноценное средство резервного копирования. Тикет с поддержкой компресси до сих пор не решен github.com/restic/restic/issues/21
ну сжатие не всегда требуется, а тулза отличная
Самое основное, чувак, место не резиновое
Сжатие это не задача бекапилки. Жмите файловой системой или что у вас там вместо хранилища.
Так есть же дедуп, уже он нехило место экономит.
На XFS точно хорошо экономит.
на XFS как раз таки совершенно нет, потому как размер экстента переменный.
btrfs или VDO точно работают :-)
> на XFS как раз таки совершенно нет, потому как размер экстента переменный.
> btrfs или VDO точно работают :-)Я проверял на своей файлопомойке с пересозданным разделом + в cron джоб стоит. Сработало. Я олдфаг с XFS у меня давние и приятные отношения.
компрессия ломает эффективность дедупликации
так это одно и тоже, просто разные слова :)
Не обязательно. Например Хаффман сжатие но не про дубли.
Нет, если применять компрессию после дедуплицикации, т.е. хранить дедуплицированные данные в сжатом виде. Правда, это добавляет разработчику хлопот по работе с этими данными.
Правильно, потом пользователи будут жаловаться, что бэкап тормозит. А когда один бит побьётся, а накроется куча данных, то будут крики, кто же это додумался вообще сжимать. Причём накроются не просто данные, когда говорят, восстановите из бэкапа, а именно сам этот бэкап!
Сжимаются уже сжатые mssql бекапы exdupe + дедуплекация.1Тб спокойно ужимается раз в 10 (у меня, когда полный бекап раз в неделю)
Скорость работы часто упрётся в скорость ssd/nvme (про hdd молчу) , но для хорошей дедуплекации чем больше памяти тем лучше как я понял. Т.е. можно гигабайтами отдавать (кратно двум)
Zstandard якобы тоже круто https://interface31.ru/tech_it/2020/12/zstandard-novyy-bystr...
kopia делает тоже самое что и restic и borg, но умеет и компрессию и депубликацию и шифрофку и еще много чего, что нет у тех двоих. Написана кстати так же как и restic, на Го, так что портабилити гарантированно
Написано что поддерживает компрессию тут:
---
https://borgbackup.readthedocs.io/en/stable/
---
Compression
All data can be optionally compressed:lz4 (super fast, low compression)
zstd (wide range from high speed and low compression to high compression and lower speed)
zlib (medium speed and compression)
lzma (low speed, high compression)
Система резервного копирования - добро.
Из аналогов есть Duplicati, тоже поддерживает разные бэкенды и шифрование.
Пованивает дотнетом
RESTful или RESTless ?!
FUSEful.
держите restic-1.0-RELEASE. Распространяю под лицензией MIT.tar -cf - "$@" | gzip -9 | gpg2 -c
Необходимость вызывать компрессор gzip перед gpg отсутствует, т.к.
gpg по умолчанию сжимает файл пред шифрованием.
сразу видно: юниксвей. Спасибо за инфу though, лучше и вовсе отказаться от gpg в пользу более поддающихся скриптованию альтернатив
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT.
> tar -cf - "$@" | gzip -9 | gpg2 -cИ какая именно часть тут отвечает за дедупликацию и версионирование?
>>tar -cf - "$@" | gzip -9 | gpg2 -c
>И какая именно часть тут отвечает за дедупликацию и версионирование?Как обычно в Linux - то, что справляется с этой задачей лучше: ZFS
>>>tar -cf - "$@" | gzip -9 | gpg2 -c
>>И какая именно часть тут отвечает за дедупликацию и версионирование?
> Как обычно в Linux - то, что справляется с этой задачей лучше: ZFSКак обычно в Linux - т.е. достаточно хреново.
Размеро-эффективность (не говоря уже о ресурсожорстве) дедупликации в ZFS ни в какое сравнение не идет с дедупликацией чанками/rolling hash.
другая, очевидно. Глупый вопрос.
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT.
> tar -cf - "$@" | gzip -9 | gpg2 -c...
> другая, очевидно. Глупый вопрос.Глупая отмазка.
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT.Круто, а теперь дифференциальный бэкап покажи. Ты же не предлагаешь терабайты каждый раз так?
Да инкрементная мода не проблема: tar --listed-incremental...
Проблема только в том, что там с этим есть бага, которая висит десятилетие и всем все пох, пока не наступят на грабли, ну и дедупликацией там вообще не пахнет
см. dar: https://habr.com/ru/post/215449/
Как насчет p7zip? Сжимает, шифрует - все в одном.
Да, кстати, придется сначала затарить для сохранения прав и и.т.д.
Как эта система в сравнении с Bacula/Bareos ?
>Как в сравнении с Bacula/Bareosнужно
Это имхо уже более "энтерпрайзное" решение, в плане того, что больше рассчитано на наличие десяток/сотен машин и непосредственно бекапного сервера.
Это приблизительно как, ну как там - "Белаз по сравнению с жигулями?"
Один для интерпрайзов, а другой для одиночек, хотя если исползовать kopia вместо сабжа, то она позволяет в одну репу гнать файло с разных машин
Я правильно понимаю? В данном случае белаз это рестик для интерпрайзов, а жигули это бакула для одиночек?
Ведь совершенно очевидно, что рестик как канонический софт следующий философии unix способен интегрироваться в любое сколько угодно гетерогенное, сложное и масштабное окружение с мнимальной шел обвязкой (есть и продукты на основе него, например k8up). Бакула же - nero burning rom из мира резервного копирования. Какие свистелки дали - теми и пользуйся. Интегрироваться в общую систему мониторинга и алертинга - не положено. Современные средства хранения - у майнтейнера до сих пор ленты на уме... и т.д.
> Я правильно понимаю? В данном случае белаз это рестик для интерпрайзов, а
> жигули это бакула для одиночек?бакула - это в основном интерпрайзное решение, а рестик, борг, копия прекрасно можно гонять на отдельно взятом хосте без централизованных решений
Все эти системы работают с сервера, на котором лежат оригинальные файлы. Если сервер скомпрометирован, злоумышленник может получить доступ к бэкапам. Как с этим бороться?
а зачем ему зашифрованные бэкапы, если он уже имеет доступ к оригинальным файлам? Башкой думай иногда
Чтобы их стереть? Не?
а кто сказал, что рестик пишет не в append-only хранилище? Башкой думай иногда
А насколько оно "append-only" с точки зрения админа того сервера, где оно живёт?
Если копирование идет не на ту же машину, то "append-only" не обойти.
В ОП посте написано про rest-server.
Так, sshfs, ведь. Мапиш удаленную тачку к себе и бэкапишь, дольше конечно, но зато секьюрно
> в облаках Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage и Google Cloud StorageНельзя украсть ваши данные в облаке, потому что это уже не ваши данные.
крадут обычно не свое, ибо свое красть не зачем.
А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.?
Чтобы удобно было пользоваться
> Формат правил игнорирования привычен и напоминает rsyncПолучается, rsync тоже удобен.
Как минимум он лучше того что перечислил тот ламак для копирования по сети только дельты а не всех терабайтов.
> Как минимум он лучше того что перечислил тот ламак для копирования по
> сети только дельты а не всех терабайтов.Вот ведь лошара, элементарным tar ом пользоваться не умеет, но туда-же.
> Как минимум он лучше того что перечислил тот ламак для копирования по сети только дельты а не всех терабайтов.https://www.gnu.org/software/tar/manual/html_node/Incrementa...
Some time later you create another incremental backup. You will then see:$ tar --create \
--file=archive.2.tar \
--listed-incremental=/var/log/usr.snar \
/usr
tar: usr/local/db: Directory is new
usr/local/db/
usr/local/db/data
usr/local/db/index
The created archive ‘archive.2.tar’ will contain only these three members.
А точно ламак он, а не не ты, 294й?
> А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.?Ну и как ими сделать инкрементальный дедуплицированный бэкап ?
Значит так, берёшь tar в одну руку…
> Значит так, берёшь tar в одну руку…И в чем проблема то?
--listed-incremental=
--incremental
Ну примерно, да, у меня так еженедельные бэкапы сделаны. Tar в одной руке и rsync во второй. И sha256sum для надёжности. Справедливости ради, чтобы дедуплицировать фалы в тарболе, понадобится lrzip, и тот тоже работает только на файлах до скольких-то там гигабайт. Можно ещё zstd дедуплицировать -- на максимальном размере окна он дедуплицирует в пределах 2гб и работает всё же ощутимо быстрее.
> Ну примерно, да, у меня так еженедельные бэкапы сделаны. Tar в одной
> руке и rsync во второй. И sha256sum для надёжности. Справедливости ради,
> чтобы дедуплицировать фалы в тарболе, понадобится lrzip, и тот тоже работает
> только на файлах до скольких-то там гигабайт. Можно ещё zstd дедуплицировать
> -- на максимальном размере окна он дедуплицирует в пределах 2гб и
> работает всё же ощутимо быстрее.Дедупликация в бакапах??? Мда... месье знает толк в извращениях.
Бакап должен быть "атомарным"
Он никому ничего не должен. Зачем мне много копий одних данных в бэкапе? Это не эффективно. Достаточно того, что бэкапы и так дублируют друг друга на 99%. А если файл битый, то он уже битый, нет никакой разницы. Хотя вполне можно и дедуплицировать в 1 файл (особенно старые данные), всё равно данные надёжно сохранены в нескольких местах.
>Бакап должен быть "атомарным"Значение знаешь?
Ты почитай как она работает и все вопросы отпадут. Это весьма простой и эффективный алгоритм.
Тебя же не пугает сложность файловой системы, в которой файл хранится как список указателей на блоки в разделе. Почему тебя пугает что у рестика файл хранится как список указателей на уникальные блобы? Как будто бы тут есть разительное отличие в сложности.
Я например часто делаю бекап и через pipe посылаю его в рестик (чаще всего так делаю в кубере, где постоянное хранилище - дорого), который находит изменившиеся блоки и загружает их в S3 ничего никуда лишний раз не записывая.
Как ты предлагаешь сделать такой же сценарий из tar? Хранить предыдущую резервную копию? Чтобы потом сделать текущую копию, посмотреть что изменилось каким-то отдельным процессом, и это изменившееся не дедуплицированно выгрузить? Т.е. использовать место х3 в сравнении с рестиком и еще получить пенальти от отсутствия дедупдикции?
Кто эти кривые полурабочие баш портянки потом будет поддерживать, когда тебя переедет автобус?
Великолепные решения.
>> Значит так, берёшь tar в одну руку…
> И в чем проблема то?
> --listed-incremental=
> --incrementalGood luck:
https://unix.stackexchange.com/questions/411324/is-it-possib...
https://unix.stackexchange.com/questions/463898/tar-potentia...
https://bugs.launchpad.net/freezer/+bug/1570304
https://lists.gnu.org/archive/html/bug-tar/2008-07/msg00005....
https://lists.gnu.org/archive/html/bug-tar/2016-07/msg00025....
https://lists.gnu.org/archive/html/bug-tar/2016-07/msg00026....
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648048
> И в чем проблема то?
> --listed-incremental=
> --incrementalдедуплицированный бэкап ?
> А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.?Оно умеет в дедуп и дельту поблочно (причем блоки не фиксированного размера), что эффективней для больших файлов.
А вот скажите, какие есть методы против вытеснения данных в бекапах?
Отличный инструмент.
Очередной файловый бекап. Как известно каждый гордый админ локалхоста обязан написать:
1. Файловый бекап
2. Биллинговую систему
3. Текстовый редактор
4. Систему мониторинга
5. Систему управления локалхостом
6. Командный интерпретатор
7. Графический редактор
... ну и так далее - продолжать можно до бесконечности.Кратко, чисто файловый бекап - никому не нужен. Нужен бекап который умеет нормально бекапить БД, виртуалки, почтовые системы, ЕСМ-системы и прочую прикладуху. А файловых бекапов - достаточно уже имеющихся.
Комбайн, умеющий сразу всё - не юникс-вей. Вам не на опеннет, а на ихбт или еще куда-нибудь.
Годы ты тут увидел комбайн, болезный? Есть задача - делать бекапы. И централизованное управление этим процессом, чтоб потом не было "ой, а мы забыли".
Соответственно необходимо бекапить все возможные источники данных, а не только файлы, в которых хранится дай бог если пару процентов всей критично важной инфы, и во все возможные варианты хранения - не только никому не нужные облака, но и в первую очередь на ленту и схд
Вы даже не осознаете своих когнитивных искажений. Когда на винде вырос как специалист, то уже всё. Наученные программированию на бейсике и питоне туда же.
Одна задача делать бэкапы? Мелко мыслите - решайте сразу задачу "заработать денег". Одной программой для всех процессов.Даже если вам надо бэкапить базу данных, у вас все равно сначала что-то будет из нее делать какой-то дамп в файл, и потом копирование, которое что таром, что тупо цп делается одинаково. Куда все это копируется - разруливается на уровне монтирования директории на уровне ФС. Лента, СХД, объектное хранилище - пофигу. Дамп отдельно, монтирование шары отдельно, копирование отдельно - это юникс-вей. Да, чтобы не было ой мы забыли - крон.
Нда... Очередной гордый админ локалхоста...
Для начала рекомендую подробней изучить вопрос с проблемами получения консистентного бекапа бд без ее остановки.. Гарантирую кучу интересных открытий.
Далее, вот у меня один из небольших заказчиков - менее 5000 рабочих мест. Угадай сколько у него заданий бекапав в неделю? Угу не одна сотня. Предлагаешь всем этим управлять и контролировать ручками?
В опенсорце есть пара примеров почти полноценных бекапов, тот же bareos. Но ключевые слово как обычно почти...
Я изучал вопросы. Для себя решал задачу бэкапом с ридонли реплики.
Читал backup&recovery и много чего еще. 15 лет в бизнесе.Ручками это у вас в винде происходит. В юниксах вы один раз пишете скрипт, кладете его где нужно в крон и забываете. Есть системы управления конфигурациями.
Юниксовые инструменты сложно освоить, особенно если перед этим десять лет мышкой возили в тим вьюере. Но это не значит, что они плохие.
Написал скрипт? Уволен!
Потому что такой поход - порождающий систему, в которой не может разобраться, окромя немытого и бородатого гуру, который ее состряпал на коленке.
Посему у меня в департамете требуется прежде чем написать скрип, требуется:
1. Написать необходимость написать скрипт
2. Сделать на него ТЗ.
3. Передать его в департамент разработки
4. Получить не только сам скрипт, но и ОПР.
5. Пройти ПМИ.
6. Согласовать его с СБ.
И только после этого - можешь использовать свой крипт.Только благодоря такому подходу - система работает. Даже если завтра весь отдел администрирования - внезапно умрет.