|
|
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
Вообщем есть некая облачная система, включающая в себя postgresql, elk, nginx, kubernetes ... ну, ещё несколько приложений. Задача - делать регулярные бэкапы всех баз и конфигураций. Причём хотелось бы иметь какой-то элементарный веб интерфейс для отслеживания и управления этим процессом. Под управлением я здесь понимаю восстановление из бэкапов. Пытаюсь решить вопрос - искать какое-то готовое решение или реализовать всё подручными средствами, т.е. скриптами. Т. е. что хочется получить: 1. Допустим делаю ежедневный бэкап. Мне надо с нескольких серверов БД сделать бэкапы баз, с n-го количества нодов сделать копии конфигурационных файлов, отследить, что всё это выполнилось и разложить эти бэкапы так, чтобы была понятна связь с нодами и приложениями. 2. Если не все бэкапы сделаны, то нужно уведомление о проблеме. 3. После решения проблемы - бэкап того, что не сделано. 4. Ну и восстановление, с минимальным количеством ручных действий. 5. Предполагаю, что бэкапы БД делаю штатными средствами БД. Поделитесь, кто что использует для подобных задач. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2019, 01:27 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
если в общем,то любая система резервного копирования с этим справится. Для начала можно посмотреть в сторону bacula а вообще по факту именно бекапить есть смысл только БД, все остальное должно храниться в виде кода для чего-нибудь в духе terraform/ansible, что позволит в случае чего по сути любой сервис за считанные минуты развернуть заново ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2019, 01:56 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
azirumgaкто что использует для подобных задач. Нынче для этого модно бэкапить целую виртуалку в которой сервис развёрнут. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2019, 12:27 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
Только бэкап виртуалки с БД может вызвать гемморой при восстановлении ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2019, 13:11 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
landyТолько бэкап виртуалки с БД может вызвать гемморой при восстановлении ну так базу отдельно бекапим - по правилам. а все остальное можно и не бекаписть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2019, 13:13 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
По поводу первых трех пунктов. postgresql, elk, nginx. Их надо разделить на части. 1) Бэкап собственно хранилища информации. Оно есть в постгресе и эластике. Его легко увидеть по занимаемому объёму на диске (то что покажет du). - постргрес бекапится средствами БД. Тут надо просто почитать на сайте как они рекомендуют. https://www.postgresql.org/docs/current/backup.html - бекап (или просто sync) хранилища elk (там на самом деле только Эластик кушает место. Можно еще почитать как они рекомендуют https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html - делать это всё строго по плану в определённые окна суток. 2) Бэкап софта и настроек. - это можно делать в онлайне. Для гарантий консистентности делать снапшоты файловых систем. Почитайте. Современные ФС уже поддерживают такое. По поводу настроек в распределённых системах есть у меня мысль что их надо не бэкапить а просто держать всегда в резерве поднятые реплики. Это даже лучше и надежнее бекапов. В нжинксе тоже собственно нечего бэкапить. Только конфигурации. По kubernetes я не специалист. Не знаю как его бэкапят. Там тоже наверное есть разделентие на ядерную часть (софт) и та часть где просто лежат образы. Их можно бэкапить по факту события. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2019, 15:38 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
bga83если в общем,то любая система резервного копирования с этим справится. Для начала можно посмотреть в сторону bacula а вообще по факту именно бекапить есть смысл только БД, все остальное должно храниться в виде кода для чего-нибудь в духе terraform/ansible, что позволит в случае чего по сути любой сервис за считанные минуты развернуть заново bga83, Спасибо, мысль о том, что базы надо бэкапить, а конфиги иметь возможность пересоздать меня тоже посещала. Думаю, что это правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.05.2019, 18:05 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
mayton, по поводу бэкапов баз их стандартными средствами - да, я так и предполагал. Но хотелось бы какую-то систему для обратного восстановления. Баз много. Каждый раз, когда восстанавливаешь руками из файла, пять раз посмотришь, тот ли файл берёшь. А хочется в веб интерфейсе указать - такую-то базу на такое-то число. По конфигурациям такая же история. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2019, 00:45 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
Насчёт веб интерфейсов я не в курсе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2019, 07:44 |
|
||
|
Управление бэкапами. Выбор решения.
|
|||
|---|---|---|---|
|
#18+
azirumgamayton, по поводу бэкапов баз их стандартными средствами - да, я так и предполагал. Но хотелось бы какую-то систему для обратного восстановления. Баз много. Каждый раз, когда восстанавливаешь руками из файла, пять раз посмотришь, тот ли файл берёшь. А хочется в веб интерфейсе указать - такую-то базу на такое-то число. По конфигурациям такая же история.из бесплатных вариантов крайне сомневаюсь, что найдется что-то с агентами под различные СУБД. Но среди платных решений есть с агентами для СУБД, но ценник может неприятно удивить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.05.2019, 10:28 |
|
||
|
|
start [/forum/topic.php?fid=25&msg=39811597&tid=1481167]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 263ms |
| total: | 390ms |
| 0 / 0 |
