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

резервное копирование веб-сайта: содержимое базы данных надежно соответствует статическому содержимому без простоев?

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

Что меня беспокоит, так это то, что без простоя возникает гонка между дампом базы данных и копированием статических файлов:

Независимо от того, какой из них вы запускаете первым или запускаете ли вы их оба одновременно, один будет завершен раньше другого, позволяя пользователям, взаимодействующим с веб-сайтом, обновлять себя (например, загружая файлы и / или вызывая изменение содержимого базы данных).

Извините, если это обман, я не нашел вопроса, который уже касается именно этого.

Проверяете ли вы дамп БД и проверяете ли вы несоответствие в списке записанных имен / путей файлов и списку фактических файлов в резервной копии статического содержимого?
Я предполагаю, что метки времени на уровне файловой системы не обязательно совпадают с метками в базе данных, поэтому сравнение последних меток времени не будет надежным.

Или несоответствия настолько редки на практике, что вам просто все равно, потому что жареный сервер будет для вас гораздо большей проблемой с самого начала?

Если это поможет, мы используем соответствующие сервисы Apache2, MySQL5.

Спасибо!

Я бы сделал так:

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

Таким образом, вы можете восстановить на определенный момент времени.

Если вы используете Linux, возможно, вы могли бы использовать Снимки LVM для предотвращения изменений статических файлов.

Нет, вы переводите свой сайт в «режим обслуживания» (который обычно проявляется либо как страница «мы выполняем обслуживание», либо как альтернативный вариант, работающий на 100% только для чтения) до тех пор, пока вы не восстановите его до стабильного / согласованного состояния. Если это невозможно, вы, вероятно, должны спросить себя, стоит ли полагаться на один сервер.