Резервное копирование данных (включая mysqldumps) на S3
У нас есть веб-приложение на нескольких серверах, и мы хотим добавить дополнительный уровень избыточности путем резервного копирования ключевых данных на S3. Ключевыми данными являются база данных MySQL и папка, содержащая динамически созданные ресурсы сайта - преимущественно изображения. Какое-то решение, основанное на rsync, изначально казалось бы лучшим планом. Пару лет назад мы играли с S3cmd (в частности, с синхронизацией s3cmd) с некоторым успехом, но мы не нашли его особенно надежным, хотя с тех пор это могло измениться. Мне пришло в голову, что решение rsync может не очень хорошо работать с одним файлом db.sql, созданным с помощью mysqldump, и я предполагаю, что это означает, что вся база данных передается каждый раз, а с несколькими базами данных более 1 ГБ это будет складываться в очень много трафика (и $ s) очень быстро. С файлами изображений я мог просто передавать файлы, измененные в течение последнего дня, что было бы намного проще. Какой подход я должен смотреть?
3 ответа
Это выглядит как идеальная работа для opendedup. Дать ему шанс. Дайте нам знать, если это решит вашу проблему.
Как вы уже догадались s3cmd гораздо надежнее, как это было несколько лет назад, и многие люди используют его, включая меня, без каких-либо проблем. Также Amazon S3 не взимает плату за загрузку данных, поэтому денежный фактор не является проблемой, но, безусловно, вы хотите избежать ненужной передачи, которая в большинстве случаев происходит с резервными копиями базы данных.
У меня была та же проблема с MySQL, потому что, к сожалению, не поддерживается добавочное резервное копирование. Вот почему я написал скрипт bash, который для каждой базы данных создает таблицу в отдельном файле. После этого я сжимаю его и zdiff с предыдущей копией, игнорируя последние 2-3 строки (где mysqldump пишет текущую дату). Если между файлами нет разницы, я не синхронизирую содержимое в облаке. Недостатком этого подхода является сложность решения, которое добавляет дополнительные шаги при восстановлении данных.
Кроме того, если у вас есть слово в разработке программного обеспечения, которое вы запускаете на сервере, вы можете добавить дополнительный параметр для каждой таблицы, которая отслеживает изменения. Таким образом, исходя из этого, вы указываете сценарию резервного копирования создавать дамп только тех таблиц, которые были изменены с момента последнего резервного копирования.
Обычный Rsync - хороший выбор для резервного копирования файлов, поскольку он прост и имеет хорошую производительность. Однако, если файл был изменен во время его Rsync-ed, копия может быть повреждена. Поэтому важно убедиться, что все файлы закрыты. В вашем случае, если было несколько файлов изображений, которые были изменены и исправлены, следующий Rsync перезапишет их в любом случае, так как Rsync копирует только измененные файлы, таким образом, это похоже на процесс самовосстановления. Так что я думаю, что Rsync и save в S3 - хороший выбор здесь.