The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Доступна система резервного копирования restic 0.13

28.03.2022 15:26

После года разработки представлен выпуск системы резервного копирования restic 0.13, предоставляющей инструментарий для сохранения резервных копий в версионированном репозитории, который может размещаться на внешних серверах и в облачных хранилищах. Данные хранятся в зашифрованном виде. Возможно определение гибких правил для включения и исключения файлов и каталогов при создании резервной копии. Поддерживается работа в Linux, macOS, Windows, FreeBSD и OpenBSD. Код проекта написан на языке Go и распространяется под лицензией BSD.

Основные возможности:

  • Поддержка хранения резервных копий в локальной ФС, на внешнем сервере с доступом по SFTP/SSH или HTTP REST, в облаках Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage и Google Cloud Storage, а также в любых хранилищах для которых имеются бэкенды rclone. Для организации хранения также может быть использован специальный rest server, обеспечивающий более высокую производительность по сравнению с другими бэкендами и способный работать в режиме только для дополнения, который не позволит удалить или изменить резервные копии в случае компрометации исходного сервера и доступа к ключам шифрования.
  • Поддержка определения гибких правил для исключения файлов и каталогов при создании резервных копий (например, для исключения из резервной копии логов, временных файлов и легко воспроизводимых данных). Формат правил игнорирования привычен и напоминает rsync или gitignore.
  • Простота установки, использования и восстановления информации. Для работы с резервными копиями достаточно скопировать один исполняемый файл, который можно использовать без дополнительных настроек. Для самого исполняемого файла обеспечивается повторяемая сборка, позволяющая самостоятельно убедиться, что бинарная сборка сформирована из предоставляемых исходных текстов.
  • Поддерживаются снапшоты, отражающие состояние определённого каталога со всеми файлами и вложенными каталогами в определённый момент времени. При каждом создании новой резервной копии создаётся ассоциированный с ней снапшот, позволяющий восстановить состояние в данный момент. Возможно копирование снапшотов между разными репозиториями.
  • Для экономии трафика в процессе создания резервных копий копируются только изменившиеся данные. Для обеспечения эффективного хранения данные в репозитории не дублируются, а дополнительные снапшоты охватывают только изменившиеся данные. Система манипулирует не целыми файлами, а блоками плавающего размера, выбираемыми с использованием подписи Рабина. Информация хранится в привязке к содержимому, а не именам файлов (связанные с данными имена и объекты определяются на уровне метаданных блока). На основании SHA-256 хэша от содержимого выполняется дедупликация и исключение лишнего копирования данных.
  • Для наглядной оценки содержимого репозитория и упрощения восстановления, снапшот с резервной копией может быть примонтирован в форме виртуального раздела (монтирование осуществляется при помощи FUSE). Также предоставляются команды для анализа изменений и выборочного извлечения файлов.
  • Информация на внешних серверах сохраняется в зашифрованном виде (для контрольных сумм используется SHA-256, для шифрования AES-256-CTR, а для гарантирования целостности - коды аутентификации на основе Poly1305-AES). Система изначально рассчитана на то, что резервные копии сохраняются в окружениях не заслуживающих доверия и попадание резервной копии в чужие руки не должно скомпрометировать систему. Шифрование может обеспечиваться как по ключам доступа, так и по паролям.
  • Предусмотрена возможность верификации резервной копии по контрольным суммам и кодам аутентификации для подтверждения, что целостность файлов не нарушена и необходимые файлы могут быть восстановлены и не включают скрытых модификаций.

В новой версии:

  • Добавлена поддержка негативных шаблонов исключения. Например, "--exclude '/home/user/*' --exclude '!/home/user/.config'" для исключения всего содержимого /home/user кроме каталога /home/user/.config.
  • В команду "backup" добавлен режим "--dry-run", который при запуске с опцией "--verbose" позволяет без фактических изменений отследить, какие файлы будут включены в резервную копию.
  • В различные бэкенды хранения добавлена поддержка контрольных сумм для дополнительной проверки загружаемых данных.
  • Проведена оптимизация команды "restore", которая стала работать в два раза быстрее. Также повышена производительность команды "copy".


  1. Главная ссылка к новости (https://restic.net/blog/2022-0...)
  2. OpenNews: Релиз системы резервного копирования fsbackup 1.2pl2
  3. OpenNews: Доступен GNU Anastasis, инструментарий для резервного копирования ключей шифрования
  4. OpenNews: Релиз системы резервного копирования BorgBackup 1.1.0
  5. OpenNews: Доступна система резервного копирования Bareos 20
  6. OpenNews: Выпуск утилиты для резервного копирования rclone 1.58
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/56924-restic
Ключевые слова: restic, backup
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (75) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 16:16, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Гораздо быстрее borg backup но до сих пор не поддерживает компрессию. Поэтому в некоторых случаях размер на диске неприемлим для использования как полноценное средство резервного копирования. Тикет с поддержкой компресси до сих пор не решен github.com/restic/restic/issues/21
     
     
  • 2.8, Onon (?), 17:47, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну сжатие не всегда требуется, а тулза отличная
     
     
  • 3.10, КО (?), 18:10, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Самое основное, чувак, место не резиновое
     
     
  • 4.21, ноунейм (?), 20:11, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Сжатие это не задача бекапилки. Жмите файловой системой или что у вас там вместо хранилища.
     
  • 4.33, kvaps (ok), 22:56, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Так есть же дедуп, уже он нехило место экономит.
     
     
  • 5.34, letsmac (ok), 23:06, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    На XFS точно хорошо экономит.
     
     
  • 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 у меня давние и приятные отношения.  

     
  • 2.24, Аноним (24), 20:32, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    компрессия ломает эффективность дедупликации
     
     
  • 3.26, Sw00p aka Jerom (?), 21:31, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    так это одно и тоже, просто разные слова :)
     
     
  • 4.36, Аноним (-), 05:37, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не обязательно. Например Хаффман сжатие но не про дубли.
     
  • 3.39, Аноним (39), 07:15, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, если применять компрессию после дедуплицикации, т.е. хранить дедуплицированные данные в сжатом виде. Правда, это добавляет разработчику хлопот по работе с этими данными.
     
     
  • 4.68, Андрей (??), 01:04, 31/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно, потом пользователи будут жаловаться, что бэкап тормозит. А когда один бит побьётся, а накроется куча данных, то будут крики, кто же это додумался вообще сжимать. Причём накроются не просто данные, когда говорят, восстановите из бэкапа, а именно сам этот бэкап!
     
  • 3.66, vitektm (?), 18:12, 30/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сжимаются уже сжатые mssql бекапы exdupe + дедуплекация.

    1Тб спокойно ужимается раз  в 10 (у меня, когда полный бекап раз в неделю)

    Скорость работы часто упрётся в скорость ssd/nvme (про hdd молчу) , но для хорошей дедуплекации чем больше памяти тем лучше как я понял.  Т.е. можно гигабайтами отдавать (кратно двум)

    Zstandard якобы тоже круто https://interface31.ru/tech_it/2020/12/zstandard-novyy-bystryy-i-effektivnyy-a

     
  • 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, тоже поддерживает разные бэкенды и шифрование.
     
     
  • 2.4, keydon (ok), 16:51, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пованивает дотнетом
     

  • 1.5, Аноним (5), 16:59, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    RESTful или RESTless ?!
     
     
  • 2.6, Аноним (6), 17:26, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    FUSEful.
     

  • 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.

     
  • 3.49, Аноним (49), 12:39, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    другая, очевидно. Глупый вопрос.
     
     
  • 4.57, Аноним (-), 19:32, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > [b]держите restic-1.0-RELEASE.[/b] Распространяю под лицензией 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...
    Проблема только в том, что там с этим есть бага, которая висит десятилетие и всем все пох, пока не наступят на грабли, ну и дедупликацией там вообще не пахнет
     
  • 3.65, Аноним (65), 11:21, 30/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    см. dar: https://habr.com/ru/post/215449/
     
  • 2.45, Анонимище (?), 09:14, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Как насчет p7zip? Сжимает, шифрует - все в одном.
     
     
  • 3.46, Анонимище (?), 09:25, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да, кстати, придется сначала затарить для сохранения прав и и.т.д.
     

  • 1.9, Аноним (9), 17:55, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как эта система в сравнении с Bacula/Bareos ?
     
     
  • 2.13, Легивон (?), 18:33, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >Как в сравнении с Bacula/Bareos

    нужно

     
  • 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 +/
    а зачем ему зашифрованные бэкапы, если он уже имеет доступ к оригинальным файлам? Башкой думай иногда
     
     
  • 3.16, Аноним (16), 18:48, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы их стереть? Не?
     
     
  • 4.17, Аноним (7), 18:50, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    а кто сказал, что рестик пишет не в append-only хранилище? Башкой думай иногда
     
     
  • 5.20, YetAnotherOnanym (ok), 20:10, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А насколько оно "append-only" с точки зрения админа того сервера, где оно живёт?
     
     
  • 6.22, ноунейм (?), 20:14, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если копирование идет не на ту же машину, то "append-only" не обойти.
     
  • 2.14, Легивон (?), 18:36, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В ОП посте написано про rest-server.
     
  • 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

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

     
     
  • 2.27, Sw00p aka Jerom (?), 21:32, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    крадут обычно не свое, ибо свое красть не зачем.
     

  • 1.28, bOOster (ok), 21:44, 28/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.?
     
     
  • 2.31, Аноним (31), 22:29, 28/03/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы удобно было пользоваться
     
     
  • 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 и т.п.?

    Ну и как ими сделать инкрементальный дедуплицированный бэкап ?

     
     
  • 3.47, Аноним (47), 09:53, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Значит так, берёшь tar в одну руку…
     
     
  • 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.61, OpenEcho (?), 21:47, 29/03/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Значит так, берёшь tar в одну руку…
    > И в чем проблема то?
    > --listed-incremental=
    > --incremental

    Good luck:

    https://unix.stackexchange.com/questions/411324/is-it-possible-to-use-tar-for-

    https://unix.stackexchange.com/questions/463898/tar-potential-bug-when-increme

    https://bugs.launchpad.net/freezer/+bug/1570304

    https://lists.gnu.org/archive/html/bug-tar/2008-07/msg00005.html

    https://lists.gnu.org/archive/html/bug-tar/2016-07/msg00025.html

    https://lists.gnu.org/archive/html/bug-tar/2016-07/msg00026.html

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648048

     
  • 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.51, Аноним (51), 15:50, 29/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А вот скажите, какие есть методы против вытеснения данных в бекапах?
     
  • 1.69, Константин Брызгалов (ok), 06:07, 31/03/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отличный инструмент.
     
  • 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. Согласовать его с СБ.
    И только после этого - можешь использовать свой крипт.

    Только благодоря такому подходу - система работает. Даже если завтра весь отдел администрирования - внезапно умрет.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру