{% extends "admin/dbs/wiki/_layout.html" %} {% block wiki %}
One command tells you what this project still needs, and does the parts that are safe to do automatically:
python manage.py dbs upgrade
It applies pending DBS migrations and refreshes the shipped AI instructions itself. Anything that means editing your own code it prints, with the exact line and where it goes. It never rewrites your settings.
Pin the release in your requirements or lock file and reinstall, the same way every deploy does, with the extras you use:
pip install "django-dbs[guard]==X.Y.Z"
Inside a virtual environment DBS can run that step for you:
python manage.py dbs upgrade --self # the newest release on PyPI
python manage.py dbs upgrade --self --to X.Y.Z # exactly this one
It prints the exact pinned pip install command, with the extras installed here,
and asks before running it; --yes answers for a script. It leaves a source
checkout alone, and an interpreter outside a virtual environment too unless you add
--system-python. Pin the same version in your requirements afterwards.
python manage.py dbs upgrade --check
Changes nothing, and exits non-zero when an item needs you to act; warnings leave it passing.
python manage.py dbs upgrade --backups /var/backups/myproject
New backups are written in container format 2, which streams with flat memory. Backups written in format 1 by earlier releases still validate and restore; this command converts them, using the passphrase this project derives or sets.
When a backup cannot be read forward, the command stops and changes nothing. It never
deletes, moves or overwrites a backup: a conversion writes a new backup beside the
original, named <name>.v2.dbs (with -2,
-3 and on when that name is taken), readable by its owner alone, and validates it
end to end before it takes that name. A backup converted on an earlier run is reported, not
converted again. The message names
the safe option first — install the version that wrote the file in a separate
environment and restore from there.
Accepting that a backup is unreadable is deliberately hard to do by accident: there is no flag for it, it needs an interactive terminal, and it needs an exact typed phrase naming how many backups you are giving up. Even then nothing is deleted.
pip install django-dbs is now the backup library alone. Install the extras you
use — [guard] for the session guard's detector, [manager] for
django_dbs, [ssh] for dbs.transports — then run
python manage.py dbs upgrade. It applies the migration that seals the audit trail
and drops the SFTP targets, and tells you about each of these:
DBS_SSH_TARGETS,
DBS_SCHEDULE_PUSH_TARGET, DBS_SCHEDULE_KEEP_REMOTE and
DBS_ADMIN_CONSOLE_SHELL do nothing; delete them and let the
DBS manager pull the backups.
dbs-client is gone too.dbs schedule refuses a DBS_SCHEDULE_KEEP above five, which the
panel reads as five.DBS_TRUSTED_PROXIES lists the proxies' networks, for example
["10.0.0.0/24"], instead of a count.DBS_KDF_TIME_COST above 10 or DBS_KDF_MEMORY_COST above
262144 makes every new backup fail.managed = False are left out unless registered or listed as
-app.model in DBS_EXCLUDE_MODELS.dbs backup PATH refuses a path
that exists.pip install "django-dbs[guard]==X.Y.Z", pinned in your requirementspython manage.py dbs upgradeThat applies the migrations 0.3.0 added and reports anything else. Existing backups
restore unchanged, and the original dbs_backup and friends keep working.