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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

в дополнение к ответу Hartator:

используйте репликацию, если ваша БД предлагает ее, например. по крайней мере, репликация master/slave с одним ведомым
делать резервные копии базы данных на подчиненном сервере БД и хранить их извне (например, scp или rsync их из вашего сервера)
используйте хорошую систему управления версиями для вашего исходного кода, например. Git
используйте надежный механизм развертывания, такой как Capistrano, и напишите свои пользовательские задачи, поэтому никто не должен выполнять миграцию DB вручную
есть кто-то, кому вы доверяете, проверьте настройки брандмауэра и безопасность вашей системы вообще

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

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

Ответ 4

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

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

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

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