Являются ли приборы django надежной резервной копией базы данных?

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

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

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

Использование приборов в качестве резервной копии базы данных будет работать до тех пор, пока ваша база данных невелика. Проблема с фикстурами заключается в том, что они долго выгружаются и загружаются. Если ваши модели и приложения находятся в постоянном движении, это означает, что каждая syncdb должна перезагружать ВСЕ ваши данные для всех ваших приложений. Вы можете избежать этого, не помещая их в каталог фикстур. И тогда вам придется выборочно (вручную) загружать нужные вам приборы при смене их моделей. Таким образом, для больших баз данных или проектов, где ваши модели постоянно меняются, гораздо лучше использовать south для управления миграциями и предотвращения перезагрузки базы данных, независимо от того, поддерживаете ли вы свои резервные копии в фикстурах или дампах sql.

А в django 1.4 datadump и dataload были даже невозможны, если только данные для каждой из ваших моделей (таблиц) не могли полностью поместиться в ОЗУ, что означает, что вы, вероятно, все равно не будете использовать постоянное хранилище для своей БД.

Например, если вы используете подход Криса Патта, а ваша база данных — это postgres, для меня pg_dumpall занимает менее 30 секунд в базе данных 6 ГБ. datadump может часами выполнять своп, если у вас недостаточно оперативной памяти.