Django怎么进行数据库备份_Python编写脚本实现自动dump与定时归档-Python教程-PHP中文网

django-admin dumpdata 需显式指定 auth.contenttypes、auth.permission 等依赖表，加 --natural-foreign 和 --natural-primary 参数避免主键冲突，脚本调用须先 django.setup()，crontab 中需设置环境变量，restore 前应先 migrate 再 loaddata。

django怎么进行数据库备份_python编写脚本实现自动dump与定时归档

django-admin dumpdata 怎么用才不丢数据

直接 dumpdata 默认只导出「已注册的模型」，且默认忽略 contenttypes、auth.permission 等依赖表，上线后 migrate 失败或权限丢失就是这么来的。

实操建议：

加 --natural-foreign 和 --natural-primary，避免导出硬编码的 ID，适配不同环境主键偏移
显式列出所有关键 app：python manage.py dumpdata auth.contenttypes auth.user auth.group sessions.sessions --indent=2 > backup.json
别漏掉自定义 Permission：它们存在 auth.permission 表里，但不会被 auth app 自动包含，得单独加进去
如果用了 django.contrib.sites 或第三方如 allauth，对应表也要手动 include，否则 restore 后登录跳转 404

用 python 脚本调用 dumpdata 要绕开哪些坑

不能直接 os.system("python manage.py dumpdata...") —— 脚本常因 Django settings 加载失败而报 django.core.exceptions.AppRegistryNotReady。

正确做法是当做一个标准 Django 管理命令来写，或者用 django.setup() 显式初始化：

import os
import django
from django.core.management import call_command
<p>os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')
django.setup()  # 必须在 call_command 前</p><p>with open('/backups/dump_20240512.json', 'w') as f:
call_command('dumpdata', '--indent=2', '--natural-foreign', '--natural-primary',
'auth', 'contenttypes', 'sessions', 'myapp', stdout=f)</p>

注意点：

call_command 的参数是字符串列表形式，不是拼接的命令行字符串
stdout=f 是写入文件最稳的方式；别用 capture_output=True 再 decode 写，容易乱码
脚本里不要硬编码路径，用 settings.BASE_DIR / 'backups' 配合 pathlib 更可靠

Linux 定时归档为什么 dump 出来全是空文件

crontab 执行时没有加载用户环境变量，PYTHONPATH、DJANGO_SETTINGS_MODULE 全失效，结果 manage.py 找不到 settings，dump 出来只有 []。

Django Wrap

强戈环形山: q15040409-刻画家功能概述强戈环形山: q15040409-刻画家是一项面向实际任务的技能，主要用于平顶山: 维西翁: 1:1.0. 塔格斯: rap.github: 自动化。它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。核心要点使用时应结合输入条件选择合适的执行方式，核对必要参数、依赖环境与输出内容，并按原始要求处理异常情况。该技能适合需要稳定复用相关能力的场景，可作为自动化工作流的一部分，也便于后续检查、调整和扩展。从功能定位来看，该

下载

修复方式（选其一）：

在 crontab 条目里显式设置环境：0 2 * * * cd /opt/myproject && PYTHONPATH=/opt/myproject DJANGO_SETTINGS_MODULE=myproject.settings /usr/bin/python3 manage.py dumpdata ... > /backups/$(date +\%Y\%m\%d).json
改用 shell 包装脚本，在开头 source ~/.bashrc（不推荐，依赖交互式 shell）
更干净的做法：用 django-cron 或 celery beat 替代系统 cron，完全运行在 Django 上下文里

另外，归档前务必检查磁盘空间和文件权限：/backups 目录要让运行 cron 的用户（比如 www-data）有写权限，否则静默失败。

restore 时 migrate 冲突和外键约束怎么破

loaddata 不会自动执行 migrate，如果备份时数据库比当前代码旧，直接 load 会因字段缺失报 FieldError；如果新，又可能因字段类型不兼容崩在 IntegrityError。

安全 restore 流程：

先 python manage.py migrate --fake-initial（仅当确认模型没变过）
再 python manage.py migrate 拉到最新
最后 python manage.py loaddata backup.json
若含外键循环依赖（比如 Group → Permission ← User），加 --disable-server-side-cursors 并确保 dump 时用了 --natural-foreign

真正麻烦的是生产环境带大量数据的 restore —— loaddata 是单事务、全内存加载，100MB+ JSON 很容易 OOM。这时候得切分 dump，或改用 pg_dump/mysqldump 做物理备份，dumpdata 只适合配置类小数据。