Contao 5.6 Backup Enhancement: Media Inclusion vs. Integrity Checksum

Short answer

Do the checksum first, and make media bundling optional and off by default. A SHA-256 of the stored backup artifact is cheap, low-risk, and useful immediately. Folding the files/ directory into the same archive is a much larger change: it alters the restore procedure, the practical size ceiling, and your exposure to core updates. It is worth doing only if restoring from a single artifact is a hard operational requirement.

What is established vs. what you must confirm

Established backup engineering: a database-only dump cannot restore uploaded media; a file checksum detects corruption or tampering of the stored artifact; and a restored database is generally not byte-identical to the dump because of row ordering, auto-increment state, and engine-specific formatting.

Not established here: whether the Contao 5.6 backup you are using is core code, a Contao Manager maintenance feature, or a custom command, and which options or extension points it exposes. Confirm that in your own installation before modifying anything. Treat any claim about a specific built-in hook as unverified until you read the installed source.

Checksum: practical, with one important caveat

Storing a SHA-256 alongside the dump is straightforward and adds negligible runtime cost relative to the dump itself.

sha256sum backup-2026-10-11.sql > backup-2026-10-11.sql.sha256
sha256sum -c backup-2026-10-11.sql.sha256

The caveat: this proves the file is the file you stored. It does not prove the restored database matches the original. For that you need a second, post-restore comparison — exact row counts for critical tables, or a per-table checksum query. Note that information_schema.tables.table_rows is approximate for InnoDB, so use exact COUNT(*) where correctness matters.

Media bundling: separate artifact by default

Approach	Restore complexity	Size risk	Upgrade risk
SQL dump + separate media archive	Two steps, documented order	Bounded per artifact	Low — no core change
Single combined archive	One step, but extraction needs correct ownership and permissions	High on media-heavy sites	Depends on how you implement it

If you do combine them, extract files to the web root with the correct user and group, and keep the database import a distinct, ordered step. Partial restores — restoring only the database, or only one media subtree — become harder once the two are fused.

Size limits and compatibility

Any backup triggered through a PHP web request is bounded by upload_max_filesize, post_max_size, memory_limit, max_execution_time, and web server timeouts. Media archives grow quickly, so a CLI- or cron-driven, streamed backup is generally more reliable for media-heavy installations. Avoid patching Contao core: a wrapper script or a documented extension point survives updates, while an in-place core edit may not.

Recommended sequence

1. Add SHA-256 generation for the existing dump; verify with sha256sum -c.
2. Keep media as a separate archive with its own checksum.
3. Document restore order and test it on staging, including file ownership.
4. Only then consider an optional combined-archive mode.

One detail changes the recommendation: is your backup executed through a PHP web request, or through CLI/cron? If it is web-triggered, fix the execution path before enabling media bundling; if it is already CLI, the size concern is mostly disk space and restore time.