我有一个使用Postgres数据库的Django应用程序。我需要能够备份和恢复数据库,以确保没有数据丢失,并且能够在测试期间将数据从生产服务器复制到开发服务器。
似乎有几种不同的方法可以做到这一点:
直接与db进行交互。因此,对于Postgres,我可以使用pg_dumpall
和psql
编写脚本。
使用Django附带的sqlclear
/ sqlall
命令。
使用Django附带的dumpdata
/ loaddata
命令。因此,从要备份的数据库中创建新的fixture,然后将它们加载到要恢复的数据库中。
使用像django-dbbackup这样的Django插件。
我真的不明白这些不同技术的优点/缺点。
刚刚开始:选项1是特定于数据库的,选项3似乎更适合设置初始数据。但我仍然不确定选项4对选项2有什么优势。
答案 0 :(得分:23)
选项1-3的问题在于备份中的媒体文件(通过FileField
上传的任何内容)未包含。可以单独备份包含媒体文件的目录。但是,由于Django在FileField
不再引用文件时不会删除文件,因此您将不可避免地得到备份中不需要存在的文件。
这就是我选择#4的原因。特别是,我建议django-archive * 。它的一些功能包括:
转储所有重要模型的内容(默认情况下ContentType
,Permission
和Session
被排除,因为它们由manage.py migrate
填充,并允许您选择要排除的其他模型。
包含FileField
和ImageField
字段引用的媒体文件。请注意,仅包含数据库中行引用的文件;被删除的行留下的文件将被忽略。
生成包含数据库备份和媒体文件的单个存档。
提供用于自定义存档档案的位置,文件名格式和存档类型(gz
和bz2
)的选项。
安装就像将django_archive
添加到INSTALLED_APPS
并在settings.py
中设置选项(如果需要)一样简单。安装后,您可以通过运行:
./manage.py archive
* 免责声明:我是该套餐的作者
答案 1 :(得分:20)
对于常规备份,我会使用PostgreSQL自带的本机工具选择选项1,因为它可能是最有效的。
我认为选项2主要涉及创建表和加载初始数据,因此不适合备份。
选项3可以用于备份,如果您需要迁移到不同的数据库平台,因为数据以非SQL形式转储,即Django理解的JSON,这将非常有用。
选项4该插件似乎使用db自己的备份工具(根据选项1),但另外提供帮助将备份推送到Amazon S3或Dropbox中的云存储