Стратегия резервного копирования для django

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

EDIT:

Что я хочу сделать резервную копию?

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

Ответ 1

Я не уверен, что есть один размер, который подходит для всех, особенно потому, что вы не сказали , что, которое вы планируете делать. Моя обычная МО:

Исходный код: используйте источник управления, например svn или git. Это означает, что у вас обычно будут: dev, deploy и резервные копии репозитория для кода (особенно в drsc).
База данных: это также зависит от использования, но обычно:
- Имейте команду управления dump_database.py, которая будет анализировать настройки, и для каждого db выведет правильную команду db dump (с учетом типа db, а также имени базы данных).
- Задайте задачу cron на другом сервере, которая подключается через ssh к серверу приложений, выполняет команду управления dump db, заставляет файл sql с именем db + timestamp в качестве имени файла и загружает его на другой сервер (amazon s3 в моем случае).
Файл мультимедиа: например. загрузка пользователей. Сохраните задание cron на другом сервере, который может передать ssh на сервер приложений и вызывает rsync на другой сервер.

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

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