LINUX.ORG.RU
решено ФорумAdmin

Многопоточный бекап, скрипт

 ,


0

3

С наступающим! :)

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

На текущий момент это все делается последовательно:

- делаем дамп первой базы

- пакуем первую базу в архив

- копируем первую базу на другой сервер

- делаем дамп второй базы

- пакуем вторую базу в архив

- копируем вторую базу на другой сервер

...

- пакуем веб контент из одной директории в архив

- пакуем веб контент из второй директории в архив

...

- копируем на другой сервер запакованный веб контент из первой директории

- копируем на другой сервер запакованный веб контент из второй директории

....

Все это занимает много времени и поскольку у сервака достаточно вычислительных ресурсов, хотелось бы сделать многопоточный бекап.

Т.е. делим всю информацию, которую хотим бекапить на объекты. Далее для каждого типа объекта (у меня их два: mysql база и директория) пишу вспомогательный скрипт, который будет его бекапить и переносить куда надо. (тут все просто и вопросов нет)

Еще будет основной скрипт, который должен запускать первый скрипт приминительно к конкретным объектам, которые надо бекапить. НО не последовательно, а параллельно группами. Т.е. допустим у меня 100 баз разного размера, я допускаю возможность бекапа 5 баз одновременно. Соответственно, этот основной скрипт, запускает 5 вспомогательных скриптов, которые бекапят базы и ждет, пока один из них не закончит работу, как закончил он запускает еще один скрипт и т.д., пока все базы не обработает.

Т.е. мне нужна возможность параллельно держать запущенными определенное количество задач, и по мере их выполнении добавлять новые задачи, пока они не закончатся. Надеюсь понятно объяснил.

Собственно вопрос, как скрипт может контролировать количество запущенных им в фоне задач, чтобы по мере их выполнения запускать новые задачи и поддерживая одновременное количество выполняемых задач на определенном уровне?



Последнее исправление: samson_b (всего исправлений: 3)
Ответ на: комментарий от anonymous

Еще вопрос возник, сам rdiff-backup по сути хранит бекапы в виде копии исходных файлов, но в отдельной директории и права у них такие же, как у исходных файлов. Как можно защитить их от изменения, чтобы тот у кого есть доступ к исходным файлам, в том числе shell, не мог удалить/изменить бекапы?

samson_b
() автор топика
Ответ на: комментарий от samson_b

в виде копии исходных файлов, но в отдельной директории

у кого есть доступ к исходным файлам, в том числе shell, не мог удалить/изменить бекапы?

Вот это ты загнул! С «партизанами» борешься? А доступ у этого «у кого есть доступ» к «отдельной директории» есть?

anonymous
()
Ответ на: комментарий от samson_b

В нормальном мире, для этого бекапы хранят на отдельной машине. Если есть шелл доступ к машине, довольно высока вероятность повышения привилегий через незакрытую дырку в ядре. Тогда тебя особо стандартные пермишшены не спасут.

anonymous
()
Ответ на: комментарий от samson_b

Именно поэтому в моём скрипте есть mount -o ro. Надёжнее, конечно, забирать файлы по сети на другую машину. (в другом здании в другой стране на далёком континенте иной планеты).

legolegs ★★★★★
()
Ответ на: комментарий от legolegs

Надёжнее, конечно, забирать файлы по сети на другую машину.

Ничего подобного. Хэш на другие машины с автоматической закачкой по BT. А твой способ слаб.

anonymous
()
Ответ на: комментарий от anonymous

Вот это ты загнул! С «партизанами» борешься? А доступ у этого «у кого есть доступ» к «отдельной директории» есть?

Ни с кем я не борюсь, у главного девелопера есть shell доступ (не root), он себе его выбил через руководство. Я был против, но я работаю по правилам компании. Так же я понимаю, что если есть у одного, может быть и у другого, и вообще утечь на сторону.

Продумываю, как мне делать бекапы. Изначально была идея делать бекап двумя способами:

1. rsync на отдельный сервер, в другом датацентре. Защищая таким образом от выхода основного сервера из строя, его физического уничтожения или даже изъятия.

2. rdiff-backup на сам основной сервер. Это уже защита от случайного/намеренного удаления/модификации данных. Я предполагал, что смогу бекапить в файл, на котором будет только root доступ, но как оказалось, что rdiff-backup, не смотря на то, что он может хранить несколько бекапов, бекапит исходные файлы просто в папку с их исходными правами.

Возможно имеет смысл отказаться от rsync, т.к. его схема работы полностью перекрывается возможностями rdiff-backup и бекапить сервер только с помощью rdiff на сам основной сервер и на сервер бекапов.

samson_b
() автор топика
Ответ на: комментарий от samson_b

бекапит исходные файлы просто в папку с их исходными правами.

Если у папки будут права на исполнение толко у тебя и rdiff, открыть (или что-то ещё) сможете только ты и rdiff.

anonymous
()
Ответ на: комментарий от anonymous

Если у папки будут права на исполнение толко у тебя и rdiff, открыть (или что-то ещё) сможете только ты и rdiff.

Спасибо! Мне почему-то казалось, что если есть права та вложенную директорию, то можно в нее «перепрыгнуть» не смотря на права доступа на корневую директории, а так нельзя, только что проверил. Проблема решена (точнее ее и не было).

Обожаю этот форум, сколько я тут знаний получил и решений для моих проблем.

samson_b
() автор топика
Ответ на: комментарий от samson_b

Из-за этого юзеры не смогут сами вытаскивать свои файлы из бекапа. Мне на локалхосте это не подходило, ты же можешь расшарить бекап через какую-то сетевую фс в режиме read-only.

legolegs ★★★★★
()
Ответ на: комментарий от legolegs

За более чем 5 лет вытаскивание пригодилось один раз всего, можно им будет сделать read-only ftp-шку для восстановления, но скорее всего меня попросят восстановить.

samson_b
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.