Назад | Перейти на главную страницу

Резервное копирование данных (включая mysqldump) на S3

У нас есть веб-приложение на нескольких серверах, и мы хотим добавить дополнительный уровень избыточности, выполняя резервное копирование ключевых данных на S3. Ключевыми данными являются база данных MySQL и папка, содержащая динамически создаваемые ресурсы сайта - преимущественно изображения. Первоначально лучшим планом могло бы показаться какое-то решение на основе rsync. Пару лет назад мы играли с S3cmd (в частности, s3cmd sync) с некоторым успехом, но мы не сочли его особенно надежным, хотя с тех пор это могло измениться. Мне пришло в голову, что решение rsync может не работать особенно хорошо с одним файлом db.sql, созданным с помощью mysqldump, и я предполагаю, что это означает, что вся база данных передается каждый раз, с несколькими базами данных размером более 1 ГБ это добавит до много трафика (и $ s) очень быстро. С файлами изображений я мог просто передавать файлы, измененные за последний день, что было бы намного проще. На какой подход я должен смотреть?

Мне это кажется идеальной работой для opendedup. Дать ему шанс. Сообщите нам, если это решит вашу проблему.

Как вы догадались s3cmd намного надежнее, чем несколько лет назад, и многие люди используют его, включая меня, без каких-либо проблем. Также amazon S3 не взимает плату за загрузку данных, поэтому денежный фактор не является проблемой, но определенно вы хотите избежать ненужной передачи, которая чаще всего происходит с резервными копиями базы данных.

У меня была такая же проблема с MySQL, потому что, к сожалению, не поддерживает инкрементное резервное копирование. Вот почему я написал сценарий bash, который для каждой базы данных выгружает таблицу в отдельный файл. После этого сжимаю и zdiff с предыдущей копией, игнорируя последние 2-3 строки (где mysqldump пишет текущую дату). Если между файлами нет разницы, я не синхронизирую контент в облаке. Обратной стороной этого подхода является сложность решения, которое требует дополнительных шагов при восстановлении данных.

Также, если у вас есть какие-либо сведения о разработке программного обеспечения, которое вы запускаете на сервере, вы можете добавить дополнительный параметр для каждой таблицы, которая отслеживает изменения. Таким образом, вы указываете своему сценарию резервного копирования сбрасывать только те таблицы, которые были изменены с момента последнего резервного копирования.

Plain Rsync - хороший выбор для резервного копирования файлов, поскольку он прост и имеет хорошую производительность. Однако, если файл изменяется во время Rsync-ed, копия может быть повреждена. Поэтому очень важно убедиться, что все файлы закрыты. В вашем случае, если было изменено и исправлено несколько файлов изображений, следующий Rsync все равно перезапишет их, поскольку Rsync копирует только измененные файлы, поэтому это похоже на процесс самовосстановления. Поэтому я думаю, что Rsync и сохранение в S3 - хороший выбор.