{% extends "admin/dbs/wiki/_layout.html" %} {% block wiki %}

Upgrading

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.

Installing a new release

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.

In CI

python manage.py dbs upgrade --check

Changes nothing, and exits non-zero when an item needs you to act; warnings leave it passing.

Old backups

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.

From 0.6.x

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:

From 0.2.x

  1. pip install "django-dbs[guard]==X.Y.Z", pinned in your requirements
  2. python manage.py dbs upgrade

That applies the migrations 0.3.0 added and reports anything else. Existing backups restore unchanged, and the original dbs_backup and friends keep working.

{% endblock %}