| 1.1, Аноним (1), 16:16, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Гораздо быстрее borg backup но до сих пор не поддерживает компрессию. Поэтому в некоторых случаях размер на диске неприемлим для использования как полноценное средство резервного копирования. Тикет с поддержкой компресси до сих пор не решен github.com/restic/restic/issues/21
| | |
| |
| |
| |
| 4.21, ноунейм (?), 20:11, 28/03/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
Сжатие это не задача бекапилки. Жмите файловой системой или что у вас там вместо хранилища.
| | |
| |
| |
| 6.64, Аноним (64), 10:48, 30/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
на XFS как раз таки совершенно нет, потому как размер экстента переменный.
btrfs или VDO точно работают :-)
| | |
| |
| 7.67, letsmac (ok), 20:28, 30/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
 > на XFS как раз таки совершенно нет, потому как размер экстента переменный.
> btrfs или VDO точно работают :-)
Я проверял на своей файлопомойке с пересозданным разделом + в cron джоб стоит. Сработало. Я олдфаг с XFS у меня давние и приятные отношения.
| | |
|
|
|
|
|
| |
| 3.39, Аноним (39), 07:15, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Нет, если применять компрессию после дедуплицикации, т.е. хранить дедуплицированные данные в сжатом виде. Правда, это добавляет разработчику хлопот по работе с этими данными.
| | |
| |
| 4.68, Андрей (??), 01:04, 31/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Правильно, потом пользователи будут жаловаться, что бэкап тормозит. А когда один бит побьётся, а накроется куча данных, то будут крики, кто же это додумался вообще сжимать. Причём накроются не просто данные, когда говорят, восстановите из бэкапа, а именно сам этот бэкап!
| | |
|
|
| 2.40, OpenEcho (?), 07:34, 29/03/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
kopia делает тоже самое что и restic и borg, но умеет и компрессию и депубликацию и шифрофку и еще много чего, что нет у тех двоих. Написана кстати так же как и restic, на Го, так что портабилити гарантированно
| | |
| 2.50, Maks (??), 14:49, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
 Написано что поддерживает компрессию тут:
---
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)
| | |
|
| 1.3, Аноним (3), 16:28, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Система резервного копирования - добро.
Из аналогов есть Duplicati, тоже поддерживает разные бэкенды и шифрование.
| | |
| 1.7, Аноним (7), 17:43, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
держите restic-1.0-RELEASE. Распространяю под лицензией MIT.
tar -cf - "$@" | gzip -9 | gpg2 -c
| | |
| |
| 2.15, Alex (??), 18:47, 28/03/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Необходимость вызывать компрессор gzip перед gpg отсутствует, т.к.
gpg по умолчанию сжимает файл пред шифрованием.
| | |
| |
| 3.18, Аноним (7), 18:53, 28/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
сразу видно: юниксвей. Спасибо за инфу though, лучше и вовсе отказаться от gpg в пользу более поддающихся скриптованию альтернатив
| | |
|
| 2.29, Аноним (-), 21:52, 28/03/2022 [^] [^^] [^^^] [ответить]
| +4 +/– |
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT.
> tar -cf - "$@" | gzip -9 | gpg2 -c
И какая именно часть тут отвечает за дедупликацию и версионирование?
| | |
| |
| 3.35, iCat (ok), 02:56, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
 >>tar -cf - "$@" | gzip -9 | gpg2 -c
>И какая именно часть тут отвечает за дедупликацию и версионирование?
Как обычно в Linux - то, что справляется с этой задачей лучше: ZFS
| | |
| |
| 4.48, Аноним (-), 12:34, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
>>>tar -cf - "$@" | gzip -9 | gpg2 -c
>>И какая именно часть тут отвечает за дедупликацию и версионирование?
> Как обычно в Linux - то, что справляется с этой задачей лучше: ZFS
Как обычно в Linux - т.е. достаточно хреново.
Размеро-эффективность (не говоря уже о ресурсожорстве) дедупликации в ZFS ни в какое сравнение не идет с дедупликацией чанками/rolling hash.
| | |
|
| |
| 4.57, Аноним (-), 19:32, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT.
> tar -cf - "$@" | gzip -9 | gpg2 -c
...
> другая, очевидно. Глупый вопрос.
Глупая отмазка.
| | |
|
|
| 2.37, Аноним (-), 05:39, 29/03/2022 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT.
Круто, а теперь дифференциальный бэкап покажи. Ты же не предлагаешь терабайты каждый раз так?
| | |
| |
| 3.41, OpenEcho (?), 07:40, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Да инкрементная мода не проблема: tar --listed-incremental...
Проблема только в том, что там с этим есть бага, которая висит десятилетие и всем все пох, пока не наступят на грабли, ну и дедупликацией там вообще не пахнет
| | |
|
|
| |
| 2.30, Имяреяк (?), 21:58, 28/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Это имхо уже более "энтерпрайзное" решение, в плане того, что больше рассчитано на наличие десяток/сотен машин и непосредственно бекапного сервера.
| | |
| 2.42, OpenEcho (?), 07:43, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Это приблизительно как, ну как там - "Белаз по сравнению с жигулями?"
Один для интерпрайзов, а другой для одиночек, хотя если исползовать kopia вместо сабжа, то она позволяет в одну репу гнать файло с разных машин
| | |
| |
| 3.58, Легивон (?), 20:33, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Я правильно понимаю? В данном случае белаз это рестик для интерпрайзов, а жигули это бакула для одиночек?
Ведь совершенно очевидно, что рестик как канонический софт следующий философии unix способен интегрироваться в любое сколько угодно гетерогенное, сложное и масштабное окружение с мнимальной шел обвязкой (есть и продукты на основе него, например k8up). Бакула же - nero burning rom из мира резервного копирования. Какие свистелки дали - теми и пользуйся. Интегрироваться в общую систему мониторинга и алертинга - не положено. Современные средства хранения - у майнтейнера до сих пор ленты на уме... и т.д.
| | |
| |
| 4.63, OpenEcho (?), 21:56, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Я правильно понимаю? В данном случае белаз это рестик для интерпрайзов, а
> жигули это бакула для одиночек?
бакула - это в основном интерпрайзное решение, а рестик, борг, копия прекрасно можно гонять на отдельно взятом хосте без централизованных решений
| | |
|
|
|
| 1.11, Аноним (11), 18:10, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Все эти системы работают с сервера, на котором лежат оригинальные файлы. Если сервер скомпрометирован, злоумышленник может получить доступ к бэкапам. Как с этим бороться?
| | |
| |
| 2.12, Аноним (7), 18:24, 28/03/2022 [^] [^^] [^^^] [ответить]
| –2 +/– |
а зачем ему зашифрованные бэкапы, если он уже имеет доступ к оригинальным файлам? Башкой думай иногда
| | |
| |
| |
| 4.17, Аноним (7), 18:50, 28/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
а кто сказал, что рестик пишет не в append-only хранилище? Башкой думай иногда
| | |
| |
| |
| 6.22, ноунейм (?), 20:14, 28/03/2022 [^] [^^] [^^^] [ответить]
| +2 +/– |
Если копирование идет не на ту же машину, то "append-only" не обойти.
| | |
|
|
|
|
| 2.43, OpenEcho (?), 07:46, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Так, sshfs, ведь. Мапиш удаленную тачку к себе и бэкапишь, дольше конечно, но зато секьюрно
| | |
|
| 1.19, YetAnotherOnanym (ok), 20:08, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 > в облаках Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage и Google Cloud Storage
Нельзя украсть ваши данные в облаке, потому что это уже не ваши данные.
| | |
| |
| |
| 3.32, Аноним (32), 22:42, 28/03/2022 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Формат правил игнорирования привычен и напоминает rsync
Получается, rsync тоже удобен.
| | |
| |
| 4.38, Аноним (-), 05:43, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Как минимум он лучше того что перечислил тот ламак для копирования по сети только дельты а не всех терабайтов.
| | |
| |
| 5.52, bOOster (ok), 16:12, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
 > Как минимум он лучше того что перечислил тот ламак для копирования по
> сети только дельты а не всех терабайтов.
Вот ведь лошара, элементарным tar ом пользоваться не умеет, но туда-же.
| | |
| 5.71, Аноним (-), 11:56, 31/03/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Как минимум он лучше того что перечислил тот ламак для копирования по сети только дельты а не всех терабайтов.
https://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html
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й?
| | |
|
|
|
| 2.44, OpenEcho (?), 07:48, 29/03/2022 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.?
Ну и как ими сделать инкрементальный дедуплицированный бэкап ?
| | |
| |
| |
| 4.53, bOOster (ok), 16:15, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Значит так, берёшь tar в одну руку…
И в чем проблема то?
--listed-incremental=
--incremental
| | |
| |
| 5.54, Аноним (47), 16:57, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Ну примерно, да, у меня так еженедельные бэкапы сделаны. Tar в одной руке и rsync во второй. И sha256sum для надёжности. Справедливости ради, чтобы дедуплицировать фалы в тарболе, понадобится lrzip, и тот тоже работает только на файлах до скольких-то там гигабайт. Можно ещё zstd дедуплицировать -- на максимальном размере окна он дедуплицирует в пределах 2гб и работает всё же ощутимо быстрее.
| | |
| |
| 6.55, bOOster (ok), 17:29, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Ну примерно, да, у меня так еженедельные бэкапы сделаны. Tar в одной
> руке и rsync во второй. И sha256sum для надёжности. Справедливости ради,
> чтобы дедуплицировать фалы в тарболе, понадобится lrzip, и тот тоже работает
> только на файлах до скольких-то там гигабайт. Можно ещё zstd дедуплицировать
> -- на максимальном размере окна он дедуплицирует в пределах 2гб и
> работает всё же ощутимо быстрее.
Дедупликация в бакапах??? Мда... месье знает толк в извращениях.
Бакап должен быть "атомарным"
| | |
| |
| 7.56, Аноним (47), 17:56, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
Он никому ничего не должен. Зачем мне много копий одних данных в бэкапе? Это не эффективно. Достаточно того, что бэкапы и так дублируют друг друга на 99%. А если файл битый, то он уже битый, нет никакой разницы. Хотя вполне можно и дедуплицировать в 1 файл (особенно старые данные), всё равно данные надёжно сохранены в нескольких местах.
| | |
| 7.60, Легивон (?), 21:11, 29/03/2022 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Бакап должен быть "атомарным"
Значение знаешь?
Ты почитай как она работает и все вопросы отпадут. Это весьма простой и эффективный алгоритм.
Тебя же не пугает сложность файловой системы, в которой файл хранится как список указателей на блоки в разделе. Почему тебя пугает что у рестика файл хранится как список указателей на уникальные блобы? Как будто бы тут есть разительное отличие в сложности.
| | |
|
|
| 5.59, Легивон (?), 20:50, 29/03/2022 [^] [^^] [^^^] [ответить]
| –2 +/– |
Я например часто делаю бекап и через pipe посылаю его в рестик (чаще всего так делаю в кубере, где постоянное хранилище - дорого), который находит изменившиеся блоки и загружает их в S3 ничего никуда лишний раз не записывая.
Как ты предлагаешь сделать такой же сценарий из tar? Хранить предыдущую резервную копию? Чтобы потом сделать текущую копию, посмотреть что изменилось каким-то отдельным процессом, и это изменившееся не дедуплицированно выгрузить? Т.е. использовать место х3 в сравнении с рестиком и еще получить пенальти от отсутствия дедупдикции?
Кто эти кривые полурабочие баш портянки потом будет поддерживать, когда тебя переедет автобус?
Великолепные решения.
| | |
| 5.62, OpenEcho (?), 21:48, 29/03/2022 [^] [^^] [^^^] [ответить]
| +/– |
> И в чем проблема то?
> --listed-incremental=
> --incremental
дедуплицированный бэкап ?
| | |
|
|
|
| 2.72, Аноним (-), 11:58, 31/03/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.?
Оно умеет в дедуп и дельту поблочно (причем блоки не фиксированного размера), что эффективней для больших файлов.
| | |
|
| 1.70, pofigist (?), 11:46, 31/03/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Очередной файловый бекап. Как известно каждый гордый админ локалхоста обязан написать:
1. Файловый бекап
2. Биллинговую систему
3. Текстовый редактор
4. Систему мониторинга
5. Систему управления локалхостом
6. Командный интерпретатор
7. Графический редактор
... ну и так далее - продолжать можно до бесконечности.
Кратко, чисто файловый бекап - никому не нужен. Нужен бекап который умеет нормально бекапить БД, виртуалки, почтовые системы, ЕСМ-системы и прочую прикладуху. А файловых бекапов - достаточно уже имеющихся.
| | |
| |
| 2.73, Аноним (73), 21:38, 31/03/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Комбайн, умеющий сразу всё - не юникс-вей. Вам не на опеннет, а на ихбт или еще куда-нибудь.
| | |
| |
| 3.74, pofigist (?), 18:52, 01/04/2022 [^] [^^] [^^^] [ответить]
| +/– |
Годы ты тут увидел комбайн, болезный? Есть задача - делать бекапы. И централизованное управление этим процессом, чтоб потом не было "ой, а мы забыли".
Соответственно необходимо бекапить все возможные источники данных, а не только файлы, в которых хранится дай бог если пару процентов всей критично важной инфы, и во все возможные варианты хранения - не только никому не нужные облака, но и в первую очередь на ленту и схд
| | |
| |
| 4.75, Аноним (73), 13:34, 02/04/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Вы даже не осознаете своих когнитивных искажений. Когда на винде вырос как специалист, то уже всё. Наученные программированию на бейсике и питоне туда же.
Одна задача делать бэкапы? Мелко мыслите - решайте сразу задачу "заработать денег". Одной программой для всех процессов.
Даже если вам надо бэкапить базу данных, у вас все равно сначала что-то будет из нее делать какой-то дамп в файл, и потом копирование, которое что таром, что тупо цп делается одинаково. Куда все это копируется - разруливается на уровне монтирования директории на уровне ФС. Лента, СХД, объектное хранилище - пофигу. Дамп отдельно, монтирование шары отдельно, копирование отдельно - это юникс-вей. Да, чтобы не было ой мы забыли - крон.
| | |
| |
| 5.76, pofigist (?), 14:33, 02/04/2022 [^] [^^] [^^^] [ответить]
| +/– |
Нда... Очередной гордый админ локалхоста...
Для начала рекомендую подробней изучить вопрос с проблемами получения консистентного бекапа бд без ее остановки.. Гарантирую кучу интересных открытий.
Далее, вот у меня один из небольших заказчиков - менее 5000 рабочих мест. Угадай сколько у него заданий бекапав в неделю? Угу не одна сотня. Предлагаешь всем этим управлять и контролировать ручками?
В опенсорце есть пара примеров почти полноценных бекапов, тот же bareos. Но ключевые слово как обычно почти...
| | |
| |
| 6.77, Аноним (73), 16:34, 02/04/2022 [^] [^^] [^^^] [ответить]
| +/– |
Я изучал вопросы. Для себя решал задачу бэкапом с ридонли реплики.
Читал backup&recovery и много чего еще. 15 лет в бизнесе.
Ручками это у вас в винде происходит. В юниксах вы один раз пишете скрипт, кладете его где нужно в крон и забываете. Есть системы управления конфигурациями.
Юниксовые инструменты сложно освоить, особенно если перед этим десять лет мышкой возили в тим вьюере. Но это не значит, что они плохие.
| | |
| |
| 7.78, pofigist (?), 18:37, 02/04/2022 [^] [^^] [^^^] [ответить]
| +/– |
Написал скрипт? Уволен!
Потому что такой поход - порождающий систему, в которой не может разобраться, окромя немытого и бородатого гуру, который ее состряпал на коленке.
Посему у меня в департамете требуется прежде чем написать скрип, требуется:
1. Написать необходимость написать скрипт
2. Сделать на него ТЗ.
3. Передать его в департамент разработки
4. Получить не только сам скрипт, но и ОПР.
5. Пройти ПМИ.
6. Согласовать его с СБ.
И только после этого - можешь использовать свой крипт.
Только благодоря такому подходу - система работает. Даже если завтра весь отдел администрирования - внезапно умрет.
| | |
|
|
|
|
|
|
|
