DE Skip to documentation

Operations

Backups and updates

Protect runtime data and test recovery before applying a new release.

On this page

Create an encrypted backup

shell
php bin/console app:backup create

Enter a hidden password twice, at least 14 characters. Do not pass the password as a command-line argument. The AES-256 ZIP is stored privately under var/backups; copy it off the server and store its password separately. The bundle includes a consistent SQLite snapshot, uploaded raster images, imported fonts, selected private site/layout/certification settings and a local integration key if present. It excludes environment files, SMTP/OAuth application secrets, sessions, logs, cache and application source. Preserve matching code and environment configuration separately.

Recover into staging

shell
php bin/console app:backup restore care-cms-YYYYMMDD-HHMMSS-XXXXXXXXXX.zip

Restore prompts for the password, validates allowed paths, encryption, checksums, limits and SQLite integrity, and writes to a new private staging directory under var/restores. It does not overwrite the live database or files. Review the recovered data and matching release before a controlled replacement. Current bundle limits are 2,000 files, 50 MB per entry and 200 MB total. Larger sites need a separately engineered backup process.

Upgrade existing installations

Back up first, preserve private settings and data, install the reviewed locked dependencies, and run the release's migrations. Shared-layout upgrades may also require the repeatable layout import. Do not rerun fictional demo seeding as a general client-upgrade strategy.

shell
php bin/console doctrine:migrations:migrate --no-interaction
php bin/console app:layouts:import

Update automation

Dependency proposals and scheduled CI checks are automated. Installing unreviewed code is not. Automatic patch installation is deferred until signed/versioned distribution, compatibility checks, interruption handling, backup and rollback are proven. Current checks cover PHP 8.2, 8.3 and 8.4 in the configured CI matrix. Run the pipeline against each actual candidate release and target environment; do not assume a newer PHP version is compatible merely because Symfony supports it.

Something unclear? Contact me about this guide.