Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Доступна система резервного копирования restic 0.13"	+/–
Сообщение от opennews (??), 28-Мрт-22, 16:16
После года разработки представлен выпуск системы резервного копирования restic 0.13, предоставляющей инструментарий для сохранения резервных копий в версионированном репозитории, который может размещаться на внешних серверах и в облачных хранилищах. Данные хранятся в зашифрованном виде. Возможно определение гибких правил для включения и исключения файлов и каталогов при создании резервной копии. Поддерживается работа в Linux, macOS, Windows, FreeBSD и OpenBSD. Код проекта написан на языке Go и распространяется под лицензией BSD... Подробнее: https://www.opennet.me/opennews/art.shtml?num=56924
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 28-Мрт-22, 16:16	+2 +/–
Гораздо быстрее borg backup но до сих пор не поддерживает компрессию. Поэтому в некоторых случаях размер на диске неприемлим для использования как полноценное средство резервного копирования. Тикет с поддержкой компресси до сих пор не решен github.com/restic/restic/issues/21
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #24, #40, #50

3. Сообщение от Аноним (3), 28-Мрт-22, 16:28	+2 +/–
Система резервного копирования - добро. Из аналогов есть Duplicati, тоже поддерживает разные бэкенды и шифрование.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

4. Сообщение от keydon (ok), 28-Мрт-22, 16:51	+1 +/–
Пованивает дотнетом
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

5. Сообщение от Аноним (5), 28-Мрт-22, 16:59	–1 +/–
RESTful или RESTless ?!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

6. Сообщение от Аноним (6), 28-Мрт-22, 17:26	+1 +/–
FUSEful.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

7. Сообщение от Аноним (7), 28-Мрт-22, 17:43	+2 +/–
держите restic-1.0-RELEASE. Распространяю под лицензией MIT.     tar -cf - "$@" | gzip -9 | gpg2 -c
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #29, #37, #45

8. Сообщение от Onon (?), 28-Мрт-22, 17:47	+1 +/–
ну сжатие не всегда требуется, а тулза отличная
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10

9. Сообщение от Аноним (9), 28-Мрт-22, 17:55	+/–
Как эта система в сравнении с Bacula/Bareos ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #30, #42

10. Сообщение от КО (?), 28-Мрт-22, 18:10	+5 +/–
Самое основное, чувак, место не резиновое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #21, #33

11. Сообщение от Аноним (11), 28-Мрт-22, 18:10	+1 +/–
Все эти системы работают с сервера, на котором лежат оригинальные файлы. Если сервер скомпрометирован, злоумышленник может получить доступ к бэкапам. Как с этим бороться?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #14, #43

12. Сообщение от Аноним (7), 28-Мрт-22, 18:24	–2 +/–
а зачем ему зашифрованные бэкапы, если он уже имеет доступ к оригинальным файлам? Башкой думай иногда
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #16

13. Сообщение от Легивон (?), 28-Мрт-22, 18:33	+/–
>Как в сравнении с Bacula/Bareos нужно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

14. Сообщение от Легивон (?), 28-Мрт-22, 18:36	+1 +/–
В ОП посте написано про rest-server.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

15. Сообщение от Alex (??), 28-Мрт-22, 18:47	+1 +/–
Необходимость вызывать компрессор gzip перед gpg отсутствует, т.к. gpg по умолчанию сжимает файл пред шифрованием.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #18

16. Сообщение от Аноним (16), 28-Мрт-22, 18:48	+/–
Чтобы их стереть? Не?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #17

17. Сообщение от Аноним (7), 28-Мрт-22, 18:50	+/–
а кто сказал, что рестик пишет не в append-only хранилище? Башкой думай иногда
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #20

18. Сообщение от Аноним (7), 28-Мрт-22, 18:53	+/–
сразу видно: юниксвей. Спасибо за инфу though, лучше и вовсе отказаться от gpg в пользу более поддающихся скриптованию альтернатив
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

19. Сообщение от YetAnotherOnanym (ok), 28-Мрт-22, 20:08	+3 +/–
>  в облаках Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage и Google Cloud Storage Нельзя украсть ваши данные в облаке, потому что это уже не ваши данные.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27

20. Сообщение от YetAnotherOnanym (ok), 28-Мрт-22, 20:10	+/–
А насколько оно "append-only" с точки зрения админа того сервера, где оно живёт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #22

21. Сообщение от ноунейм (?), 28-Мрт-22, 20:11	+3 +/–
Сжатие это не задача бекапилки. Жмите файловой системой или что у вас там вместо хранилища.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

22. Сообщение от ноунейм (?), 28-Мрт-22, 20:14	+2 +/–
Если копирование идет не на ту же машину, то "append-only" не обойти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

24. Сообщение от Аноним (24), 28-Мрт-22, 20:32	+1 +/–
компрессия ломает эффективность дедупликации
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #26, #39, #66

26. Сообщение от Sw00p aka Jerom (?), 28-Мрт-22, 21:31	–1 +/–
так это одно и тоже, просто разные слова :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #36

27. Сообщение от Sw00p aka Jerom (?), 28-Мрт-22, 21:32	+/–
крадут обычно не свое, ибо свое красть не зачем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

28. Сообщение от bOOster (ok), 28-Мрт-22, 21:44	+/–
А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31, #44, #72

29. Сообщение от Аноним (-), 28-Мрт-22, 21:52	+4 +/–
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT. >     tar -cf - "$@" | gzip -9 | gpg2 -c И какая именно часть тут отвечает за дедупликацию и версионирование?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #35, #49

30. Сообщение от Имяреяк (?), 28-Мрт-22, 21:58	+/–
Это имхо уже более "энтерпрайзное" решение, в плане того, что больше рассчитано на наличие десяток/сотен машин и непосредственно бекапного сервера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

31. Сообщение от Аноним (31), 28-Мрт-22, 22:29	+/–
Чтобы удобно было пользоваться
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #32

32. Сообщение от Аноним (32), 28-Мрт-22, 22:42	+2 +/–
> Формат правил игнорирования привычен и напоминает rsync Получается, rsync тоже удобен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #38

33. Сообщение от kvaps (ok), 28-Мрт-22, 22:56	+/–
Так есть же дедуп, уже он нехило место экономит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #34

34. Сообщение от letsmac (ok), 28-Мрт-22, 23:06	+/–
На XFS точно хорошо экономит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #64

35. Сообщение от iCat (ok), 29-Мрт-22, 02:56	+/–
>>tar -cf - "$@" | gzip -9 | gpg2 -c >И какая именно часть тут отвечает за дедупликацию и версионирование? Как обычно в Linux - то, что справляется с этой задачей лучше: ZFS
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #48

36. Сообщение от Аноним (-), 29-Мрт-22, 05:37	–1 +/–
Не обязательно. Например Хаффман сжатие но не про дубли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

37. Сообщение от Аноним (-), 29-Мрт-22, 05:39	+1 +/–
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT. Круто, а теперь дифференциальный бэкап покажи. Ты же не предлагаешь терабайты каждый раз так?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #41, #65

38. Сообщение от Аноним (-), 29-Мрт-22, 05:43	+/–
Как минимум он лучше того что перечислил тот ламак для копирования по сети только дельты а не всех терабайтов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #52, #71

39. Сообщение от Аноним (39), 29-Мрт-22, 07:15	+/–
Нет, если применять компрессию после дедуплицикации, т.е. хранить дедуплицированные данные в сжатом виде. Правда, это добавляет разработчику хлопот по работе с этими данными.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #68

40. Сообщение от OpenEcho (?), 29-Мрт-22, 07:34	+1 +/–
kopia делает тоже самое что и restic и borg, но умеет и компрессию и депубликацию и шифрофку и еще много чего, что нет у тех двоих. Написана кстати так же как и restic, на Го, так что портабилити гарантированно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

41. Сообщение от OpenEcho (?), 29-Мрт-22, 07:40	+/–
Да инкрементная мода не проблема: tar  --listed-incremental... Проблема только в том, что там с этим есть бага, которая висит десятилетие и всем все пох, пока не наступят на грабли, ну и дедупликацией там вообще не пахнет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

42. Сообщение от OpenEcho (?), 29-Мрт-22, 07:43	+/–
Это приблизительно как, ну как там - "Белаз по сравнению с жигулями?" Один для интерпрайзов, а другой для одиночек, хотя если исползовать kopia вместо сабжа, то она позволяет в одну репу гнать файло с разных машин
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #58

43. Сообщение от OpenEcho (?), 29-Мрт-22, 07:46	+/–
Так, sshfs, ведь. Мапиш удаленную тачку к себе и бэкапишь, дольше конечно, но зато секьюрно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

44. Сообщение от OpenEcho (?), 29-Мрт-22, 07:48	+1 +/–
> А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.? Ну и как ими сделать инкрементальный дедуплицированный бэкап ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #47

45. Сообщение от Анонимище (?), 29-Мрт-22, 09:14	+/–
Как насчет p7zip? Сжимает, шифрует - все в одном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #46

46. Сообщение от Анонимище (?), 29-Мрт-22, 09:25	+/–
Да, кстати, придется сначала затарить для сохранения прав и и.т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

47. Сообщение от Аноним (47), 29-Мрт-22, 09:53	+2 +/–
Значит так, берёшь tar в одну руку…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #53

48. Сообщение от Аноним (-), 29-Мрт-22, 12:34	+/–
>>>tar -cf - "$@" | gzip -9 | gpg2 -c >>И какая именно часть тут отвечает за дедупликацию и версионирование? > Как обычно в Linux - то, что справляется с этой задачей лучше: ZFS Как обычно в Linux - т.е. достаточно хреново. Размеро-эффективность (не говоря уже о ресурсожорстве) дедупликации в ZFS ни в какое сравнение не идет с дедупликацией чанками/rolling hash.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

49. Сообщение от Аноним (49), 29-Мрт-22, 12:39	+/–
другая, очевидно. Глупый вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #57

50. Сообщение от Maks (??), 29-Мрт-22, 14:49	+/–
Написано что поддерживает компрессию тут: --- 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)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

51. Сообщение от Аноним (51), 29-Мрт-22, 15:50	+/–
А вот скажите, какие есть методы против вытеснения данных в бекапах?
Ответить | Правка | Наверх | Cообщить модератору

52. Сообщение от bOOster (ok), 29-Мрт-22, 16:12	+/–
> Как минимум он лучше того что перечислил тот ламак для копирования по > сети только дельты а не всех терабайтов. Вот ведь лошара, элементарным tar ом пользоваться не умеет, но туда-же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

53. Сообщение от bOOster (ok), 29-Мрт-22, 16:15	+/–
> Значит так, берёшь tar в одну руку… И в чем проблема то? --listed-incremental= --incremental
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #54, #59, #61, #62

54. Сообщение от Аноним (47), 29-Мрт-22, 16:57	+/–
Ну примерно, да, у меня так еженедельные бэкапы сделаны. Tar в одной руке и rsync во второй. И sha256sum для надёжности. Справедливости ради, чтобы дедуплицировать фалы в тарболе, понадобится lrzip, и тот тоже работает только на файлах до скольких-то там гигабайт. Можно ещё zstd дедуплицировать -- на максимальном размере окна он дедуплицирует в пределах 2гб и работает всё же ощутимо быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #55

55. Сообщение от bOOster (ok), 29-Мрт-22, 17:29	+/–
> Ну примерно, да, у меня так еженедельные бэкапы сделаны. Tar в одной > руке и rsync во второй. И sha256sum для надёжности. Справедливости ради, > чтобы дедуплицировать фалы в тарболе, понадобится lrzip, и тот тоже работает > только на файлах до скольких-то там гигабайт. Можно ещё zstd дедуплицировать > -- на максимальном размере окна он дедуплицирует в пределах 2гб и > работает всё же ощутимо быстрее. Дедупликация в бакапах??? Мда... месье знает толк в извращениях. Бакап должен быть "атомарным"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #56, #60

56. Сообщение от Аноним (47), 29-Мрт-22, 17:56	+/–
Он никому ничего не должен. Зачем мне много копий одних данных в бэкапе? Это не эффективно. Достаточно того, что бэкапы и так дублируют друг друга на 99%. А если файл битый, то он уже битый, нет никакой разницы. Хотя вполне можно и дедуплицировать в 1 файл (особенно старые данные), всё равно данные надёжно сохранены в нескольких местах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

57. Сообщение от Аноним (-), 29-Мрт-22, 19:32	+/–
> держите restic-1.0-RELEASE. Распространяю под лицензией MIT. >     tar -cf - "$@" | gzip -9 | gpg2 -c ... > другая, очевидно. Глупый вопрос. Глупая отмазка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

58. Сообщение от Легивон (?), 29-Мрт-22, 20:33	+/–
Я правильно понимаю? В данном случае белаз это рестик для интерпрайзов, а жигули это бакула для одиночек? Ведь совершенно очевидно, что рестик как канонический софт следующий философии unix способен интегрироваться в любое сколько угодно гетерогенное, сложное и масштабное окружение с мнимальной шел обвязкой (есть и продукты на основе него, например k8up). Бакула же - nero burning rom из мира резервного копирования. Какие свистелки дали - теми и пользуйся. Интегрироваться в общую систему мониторинга и алертинга - не положено. Современные средства хранения - у майнтейнера до сих пор ленты на уме... и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #63

59. Сообщение от Легивон (?), 29-Мрт-22, 20:50	–2 +/–
Я например часто делаю бекап и через pipe посылаю его в рестик (чаще всего так делаю в кубере, где постоянное хранилище - дорого), который находит изменившиеся блоки и загружает их в S3 ничего никуда лишний раз не записывая. Как ты предлагаешь сделать такой же сценарий из tar? Хранить предыдущую резервную копию? Чтобы потом сделать текущую копию, посмотреть что изменилось каким-то отдельным процессом, и это изменившееся не дедуплицированно выгрузить? Т.е. использовать место х3 в сравнении с рестиком и еще получить пенальти от отсутствия дедупдикции? Кто эти кривые полурабочие баш портянки потом будет поддерживать, когда тебя переедет автобус? Великолепные решения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

60. Сообщение от Легивон (?), 29-Мрт-22, 21:11	–1 +/–
>Бакап должен быть "атомарным" Значение знаешь? Ты почитай как она работает и все вопросы отпадут. Это весьма простой и эффективный алгоритм. Тебя же не пугает сложность файловой системы, в которой файл хранится как список указателей на блоки в разделе. Почему тебя пугает что у рестика файл хранится как список указателей на уникальные блобы? Как будто бы тут есть разительное отличие в сложности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55

61. Сообщение от OpenEcho (?), 29-Мрт-22, 21:47	–1 +/–
>> Значит так, берёшь tar в одну руку… > И в чем проблема то? > --listed-incremental= > --incremental Good 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

62. Сообщение от OpenEcho (?), 29-Мрт-22, 21:48	+/–
> И в чем проблема то? > --listed-incremental= > --incremental дедуплицированный бэкап ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

63. Сообщение от OpenEcho (?), 29-Мрт-22, 21:56	+/–
> Я правильно понимаю? В данном случае белаз это рестик для интерпрайзов, а > жигули это бакула для одиночек? бакула - это в основном интерпрайзное решение, а рестик, борг, копия прекрасно можно гонять на отдельно взятом хосте без централизованных решений
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

64. Сообщение от Аноним (64), 30-Мрт-22, 10:48	+/–
на XFS как раз таки совершенно нет, потому как размер экстента переменный. btrfs или VDO точно работают :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #67

65. Сообщение от Аноним (65), 30-Мрт-22, 11:21	+/–
см. dar: https://habr.com/ru/post/215449/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

66. Сообщение от vitektm (?), 30-Мрт-22, 18:12	+/–
Сжимаются уже сжатые mssql бекапы exdupe + дедуплекация. 1Тб спокойно ужимается раз  в 10 (у меня, когда полный бекап раз в неделю) Скорость работы часто упрётся в скорость ssd/nvme (про hdd молчу) , но для хорошей дедуплекации чем больше памяти тем лучше как я понял.  Т.е. можно гигабайтами отдавать (кратно двум) Zstandard якобы тоже круто https://interface31.ru/tech_it/2020/12/zstandard-novyy-bystr...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

67. Сообщение от letsmac (ok), 30-Мрт-22, 20:28	+/–
> на XFS как раз таки совершенно нет, потому как размер экстента переменный. > btrfs или VDO точно работают :-) Я проверял на своей файлопомойке с пересозданным разделом + в cron джоб стоит. Сработало. Я олдфаг с XFS у меня давние и приятные отношения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

68. Сообщение от Андрей (??), 31-Мрт-22, 01:04	+/–
Правильно, потом пользователи будут жаловаться, что бэкап тормозит. А когда один бит побьётся, а накроется куча данных, то будут крики, кто же это додумался вообще сжимать. Причём накроются не просто данные, когда говорят, восстановите из бэкапа, а именно сам этот бэкап!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

69. Сообщение от Константин Брызгалов (ok), 31-Мрт-22, 06:07	+/–
Отличный инструмент.
Ответить | Правка | Наверх | Cообщить модератору

70. Сообщение от pofigist (?), 31-Мрт-22, 11:46	+/–
Очередной файловый бекап. Как известно каждый гордый админ локалхоста обязан написать: 1. Файловый бекап 2. Биллинговую систему 3. Текстовый редактор 4. Систему мониторинга 5. Систему управления локалхостом 6. Командный интерпретатор 7. Графический редактор ... ну и так далее - продолжать можно до бесконечности. Кратко, чисто файловый бекап - никому не нужен. Нужен бекап который умеет нормально бекапить БД, виртуалки, почтовые системы, ЕСМ-системы и прочую прикладуху. А файловых бекапов - достаточно уже имеющихся.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #73

71. Сообщение от Аноним (-), 31-Мрт-22, 11:56	+/–
> Как минимум он лучше того что перечислил тот ламак для копирования по сети только дельты а не всех терабайтов. 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й?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

72. Сообщение от Аноним (-), 31-Мрт-22, 11:58	+/–
> А оно зачем если есть tar, gzip, bzip, scp, bash, openssl и т.п.? Оно умеет в дедуп и дельту поблочно (причем блоки не фиксированного размера), что эффективней для больших файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

73. Сообщение от Аноним (73), 31-Мрт-22, 21:38	–1 +/–
Комбайн, умеющий сразу всё - не юникс-вей. Вам не на опеннет, а на ихбт или еще куда-нибудь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #74

74. Сообщение от pofigist (?), 01-Апр-22, 18:52	+/–
Годы ты тут увидел комбайн, болезный? Есть задача - делать бекапы. И централизованное управление этим процессом, чтоб потом не было "ой, а мы забыли". Соответственно необходимо бекапить все возможные источники данных, а не только файлы, в которых хранится дай бог если пару процентов всей критично важной инфы, и во все возможные варианты хранения - не только никому не нужные облака, но и в первую очередь на ленту и схд
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #75

75. Сообщение от Аноним (73), 02-Апр-22, 13:34	–1 +/–
Вы даже не осознаете своих когнитивных искажений. Когда на винде вырос как специалист, то уже всё. Наученные программированию на бейсике и питоне туда же. Одна задача делать бэкапы? Мелко мыслите - решайте сразу задачу "заработать денег". Одной программой для всех процессов. Даже если вам надо бэкапить базу данных, у вас все равно сначала что-то будет из нее делать какой-то дамп в файл, и потом копирование, которое что таром, что тупо цп делается одинаково. Куда все это копируется - разруливается на уровне монтирования директории на уровне ФС. Лента, СХД, объектное хранилище - пофигу. Дамп отдельно, монтирование шары отдельно, копирование отдельно - это юникс-вей. Да, чтобы не было ой мы забыли - крон.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #76

76. Сообщение от pofigist (?), 02-Апр-22, 14:33	+/–
Нда... Очередной гордый админ локалхоста... Для начала рекомендую подробней изучить вопрос с проблемами получения консистентного бекапа бд без ее остановки.. Гарантирую кучу интересных открытий. Далее, вот у меня один из небольших заказчиков - менее 5000 рабочих мест. Угадай сколько у него заданий бекапав в неделю? Угу не одна сотня. Предлагаешь всем этим управлять и контролировать ручками? В опенсорце есть пара примеров почти полноценных бекапов, тот же bareos. Но ключевые слово как обычно почти...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #77

77. Сообщение от Аноним (73), 02-Апр-22, 16:34	+/–
Я изучал вопросы. Для себя решал задачу бэкапом с ридонли реплики. Читал backup&recovery и много чего еще. 15 лет в бизнесе. Ручками это у вас в винде происходит. В юниксах вы один раз пишете скрипт, кладете его где нужно в крон и забываете. Есть системы управления конфигурациями. Юниксовые инструменты сложно освоить, особенно если перед этим десять лет мышкой возили в тим вьюере. Но это не значит, что они плохие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #78

78. Сообщение от pofigist (?), 02-Апр-22, 18:37	+/–
Написал скрипт? Уволен! Потому что такой поход - порождающий систему, в которой не может разобраться, окромя немытого и бородатого гуру, который ее состряпал на коленке. Посему у меня в департамете требуется прежде чем написать скрип, требуется: 1. Написать необходимость написать скрипт 2. Сделать на него ТЗ. 3. Передать его в департамент разработки 4. Получить не только сам скрипт, но и ОПР. 5. Пройти ПМИ. 6. Согласовать его с СБ. И только после этого - можешь использовать свой крипт. Только благодоря такому подходу - система работает. Даже если завтра весь отдел администрирования - внезапно умрет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема