Как подготовиться к потере данных на рабочем сайте?

Question

Я создаю приложение, которое быстро переходит в производство, и меня беспокоит вероятность того, что из-за взлома, какой-нибудь глупой личной ошибки (например, при запуске rake db:schema:load или rake db:rollback) или других обстоятельств мы можем потерять данные в одна таблица базы данных или даже по всей системе.

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

Я использую резервные копии Heroku PG (которые должны быть заменены чем-то еще в этом месяце), а также я запускаю автоматические ежедневные резервные копии на S3: http://trevorturk.com/2010/04/14/automated-heroku-backups/,, успешно генерирующие .dump файлы.

Как правильно бороться с потерей данных в производственном приложении?

1. Как мне восстановить файл .dump в случае необходимости? Могу ли я сделать выборочное восстановление, если поражена небольшая часть системы?
2. В случае, если выборочное восстановление невозможно: предположим, что одна таблица теряет данные через 4 часа после последнего резервного копирования. Результат => для исправления потерянной таблицы потребуется откат на 4 часа активности пользователей? Любое хорошее решение для этого?
3. Каков наилучший способ поддержки пользователей из-за неудобств, если что-то подобное происходит?

Answer 1

Для полного аварийного восстановления (аварийного восстановления) требуется следующее:

1. Многоузловое. Если пожар, наводнение, Усама бен Ладен или что-то еще произошло в центре обработки данных Amazon (или это Salesforce?), Который использует Heroku, вы хотите быть уверены, что ваши данные в безопасности в другом месте.
2. Текущая репликация данных на отдельный сайт (или сайты). Это означает, что каждая транзакция, которая записывается в вашу базу данных на одном сайте, реплицируется в течение нескольких секунд в зеркальную базу данных на другом сайте. Большинство СУБД имеют механизмы, позволяющие вам выполнять репликацию типа «главный-подчиненный».
3. То же самое относится ко всему, что вы помещаете в файловую систему вне базы данных, например к изображениям, файлам конфигурации XML и т. Д. S3 - хорошее решение здесь - они копируют все для нескольких центров обработки данных для вас.
4. Мне не помешает создавать периодические (ежедневно или около того) дампы базы данных и хранить их отдельно (например, на S3). Это поможет вам восстановиться после повреждения данных, которое распространяется на подчиненные БД.
5. Автоматизировать процесс восстановления данных. Вы хотите, чтобы это работало, когда вам это нужно.
6. Проверьте все. В идеале вы хотите автоматизировать процесс тестирования и периодически запускать его, чтобы обеспечить возможность восстановления резервных копий. Netflix Chaos Monkey является крайним примером этого.

Я не уверен, как бы вы реализовали все это на Heroku. Полное решение по-прежнему недоступно для большинства компаний - мы используем его в наших собственных центрах обработки данных (один в США, один в ЕС), и оно стоит много миллионов. Работайте в соответствии с правилом 80-20 - постоянное резервное копирование на отдельный сайт, а также хорошо проверенный план восстановления (непрерывное тестирование вашей способности восстанавливаться из резервных копий) покрывает 80% того, что вам нужно.

Что касается поддержки пользователей, лучшее решение - просто своевременно и правдиво сообщать о возникновении проблем и следить за тем, чтобы не потерять данные. Если ваши пользователи платят за ваши услуги (т.е. вы не поддерживаете рекламу), то, вероятно, у вас должен быть SLA.

Answer 2

Чтобы смоделировать довольно простое «полное аварийное восстановление» в Heroku, создайте еще один проект Heroku и полностью скопируйте свое производственное приложение (кроме использования другого настраиваемого доменного имени).

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

Единственный шаг, который отсутствует в этом упражнении для реального аварийного восстановления, - это присвоение рабочего домена реплицированному проекту Heroku.

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

Answer 3

в дополнение к ответу Хартатора:

• используйте репликацию, если ваша БД предлагает ее, например, по крайней мере репликацию главного / подчиненного с одним ведомым

• делать резервные копии базы данных на подчиненном сервере БД и сохранять их внешне (например, scp или rsync их с вашего сервера)

• использовать хорошую систему контроля версий для вашего исходного кода, например, Git

• использовать надежный механизм развертывания, такой как Capistrano, и писать собственные задачи, поэтому никому не нужно выполнять перенос БД вручную

• есть кто-то, кого выtrust проверьте настройки брандмауэра и безопасность вашей системы в целом

DB-Dump содержит SQL-команды для воссоздания всех таблиц и всех данных ... если вам нужно восстановить только однутаблицу, вы можете извлечь эту часть из копии файла дампа и (очень осторожно) отредактировать ее, а затем восстановить с измененным файлом дампа (для одной таблицы).

Всегда сначала восстанавливать на независимом компьютере и проверятьесли чДанные выглядят правильно.Например, вы можете использовать один подчиненный сервер, перевести его в автономный режим, затем восстановить там локально и проверить данные.Хорошо, если в вашей системе есть два ведомых, тогда в оставшейся системе все еще один ведущий и один ведомый, пока вы восстанавливаете второго ведомого.

Answer 4

Что касается резервных копий, вы не можете быть уверены на 100 процентов каждый раз, когда никакие данные не будут потеряны.Лучше всего протестировать его на другом сервере.У вас должно быть как минимум два типа резервного копирования:

• Резервное копирование базы данных, например, pg-dump.Дамп - это уникальные команды SQL, так что вы можете использовать его для воссоздания всей базы данных, только таблицы или нескольких строк.Вы теряете данные, добавленные за это время.

• Резервная копия кода, например, репозиторий git.