Feature/digital 721 backup restore s3

[jacobaaronyeager]

Jira ticket

DIGITAL-721

Purpose

This adds:

1. scripts for backing up static site and public files
2. automations for those backups
3. developer tools for downloading those files
4. convenience scripts for making installing public files easy

Deployment and testing

Local Setup

You'll need to be logged into Cloud.gov and targeting the space you want to pull from:

cf login -a api.fr.cloud.gov --sso
cf target -s dev

No rebuild needed. If you want to try the local refresh, a working Lando site is enough.

QA/Testing instructions

New scripts in /scripts pull backups from whatever space you have targeted (project and space are derived automatically):

1. ./scripts/download_files.sh — downloads the public files. Add -x to extract them into web/sites/default/files (the cms/public/ prefix is stripped so they land where Drupal expects). Without -x you just get the .tar.gz.
2. ./scripts/download_static.sh — same, for the generated static site.
3. ./scripts/refresh-local.sh — the one-step version: imports the DB, loads the files, uninstalls s3fs locally so images serve from disk, rebuilds cache, and hands you a login link. Use --no-db / --no-files to run just one part, -d YYYY-MM-DD for an older backup.

To confirm: run ./scripts/refresh-local.sh, open the login link, and check that a page with uploaded images renders (images come from sites/default/files, including the styles/ derivatives).

Backup side: the "Daily backup" action now backs up the storage and static buckets alongside the database, and there's a "Files Restore" workflow to push them back. These run against prod on the scheduled job.

Note: loading a prod DB onto a feature branch can leave config/DB drift (e.g. a module the branch expects isn't enabled, or a cim conflict on a changed field). That's expected — run lando drush cim yourself if you want your branch's config fully applied. The refresh script deliberately doesn't do that for you.

Checklist for the Developer

• A link to the JIRA ticket has been included above.
• No merge conflicts exist with the target branch.
• Automated tests have passed on this PR.
• A reviewer has been designated.
• Deployment and testing steps have been documented above, if applicable.

Checklist for the Peer Reviewers

• The file changes are relevant to the task objective.
• Code is readable and includes appropriate commenting.
• Code standards and best practices are followed.
• QA/Test steps were successfully completed, if applicable.
• Applicable logs are free of errors.