как сделать резервную копию Джанго дБ

у меня есть приложение Django, которое использует базу данных Postgres. Мне нужно иметь возможность резервного копирования и восстановления БД, чтобы убедиться, что данные не потеряны, и иметь возможность копировать данные с рабочего сервера на сервер разработки во время тестирования.

кажется, есть несколько разных способов сделать это:

  1. просто взаимодействовать с БД напрямую. Итак, для Postgres я могу написать сценарий, используя pg_dumpall и psql.

  2. использовать sqlclear/sqlall команды, которые поставляются с Django.

  3. использовать dumpdata/loaddata команды, которые поставляются с Django. Поэтому создайте новые светильники из БД, которые вы хотите создать резервную копию, а затем загрузите их в БД, которую вы хотите восстановить.

  4. используйте плагин Django, как Джанго-dbbackup.

Я действительно не понимаю плюсы/минусы этих различных методов.

просто с верхней части моей головы: Вариант 1 зависит от базы данных, а Вариант 3, как представляется, больше подходит для настройки исходных данных. Но я все еще не уверен, какие преимущества имеет вариант 4 над вариантом 2.

31
database-backups database-restore django

2 ответов

для регулярных резервных копий я бы выбрал вариант 1, используя собственный собственный инструмент PostgreSQL, поскольку он, вероятно, наиболее эффективен.

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

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

Вариант 4 плагин, похоже, использует собственные инструменты резервного копирования БД (согласно варианту 1), но дополнительно предоставляет помощь, чтобы подтолкнуть ваши резервные копии в облачное хранилище в Amazon S3 или Dropbox

18

проблема с вариантами 1-3 заключается в том, что медиа-файлы (все, что загружено через FileField) составляют не входит в резервной копии. Можно отдельно создать резервную копию каталога, содержащего медиафайлы. Однако, потому что Django не удаляет файлы, когда на них больше не ссылается FileField, вы неизбежно закончите с файлами в резервной копии, которые не должны быть там.

вот почему я бы пошел с вариантом №4. В частности, я рекомендую django-архив*. Некоторые из его особенностей включают в себя:

  • выводит содержимое всех важных моделей (по умолчанию ContentType, Permission и Session исключены, так как они заполнены manage.py migrate) и позволяет выбрать дополнительные модели, чтобы исключить.

  • включает в себя медиа-файлы, на которые ссылается FileField и ImageField поля. Обратите внимание, что только файлы, на которые ссылаются строки в базе данных включены; файлы, оставленные удаленными строками, игнорируются.

  • создает единый архив, содержащий как резервные копии базы данных, так и медиафайлы.

  • предоставляет опции для настройки местоположения, где должны храниться архивы, формат файла и тип архива (gz и bz2).

установка так же просто, как добавление django_archive to INSTALLED_APPS и настройка параметров в settings.py при необходимости. Однажды установлен, вы можете сразу создать архив всей базы данных (включая медиа-файлы) с помощью команды:

./manage.py archive

* отказ от ответственности: я автор пакета

21