mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-09 05:25:14 +09:00
Aleksei Sviridkin
01feb368a1
The redis backup demo read cozy-default-redis once and gave up if it was absent. That strategy is rendered behind a lookup of the platform bucket, so it only exists after a Helm upgrade that runs once the bucket is provisioned. The backupstrategy-controller forces that upgrade, but helm-controller will not run it while a release in the chart's dependsOn is not Ready. A platform change shortly before the suite starts is enough to hold it back. The e2e install patches the platform package late (exposed services, then OIDC), the operator rewrites the cozystack-basics release, which then waits on its own dependencies, and backupstrategy-controller waits on cozystack-basics. On one run the strategy was still missing eight minutes after those patches, and the demo's single read failed the suite as if the backups stack were not installed. Wait for the object with a bound instead. 15 minutes covers the nine minutes seen between those patches and the strategy's creation on another run, and still leaves the demo inside its 30 minute step. Assisted-by: LLM Signed-off-by: Aleksei Sviridkin <f@lex.la>
Redis backup / restore demo
Proves an honest data round-trip for a Cozystack-managed Redis (spotahome RedisFailover) through the platform system bucket: a sentinel marker key is written, backed up, and asserted to return byte-for-byte after both restore flows.
The spotahome operator ships no backup CRD, so the strategy.backups.cozystack.io/Redis driver runs a one-shot Job that dumps an RDB snapshot to S3 and replays it on restore (RDB → RESP via redis-cli --pipe). This is the cozy-default-redis strategy the cozy-default BackupClass binds Redis to.
Prerequisites
- A Cozystack cluster with the
backupstrategy-controllerrunning and its system bucket provisioned, socozy-default(and thecozy-default-redisstrategy) are present and the controller can projectcozy-backups-credsinto the app namespace. kubectlpointed at the cluster; the tenant namespace defaults totenant-test(override withNAMESPACE).
Run
./run-all.sh # steps 01-04: provision, back up, restore in-place, restore to-copy
SKIP_RESTORE=1 ./run-all.sh # stop after a successful backup
./cleanup.sh # remove everything the demo created
Or step through them:
| Step | Script | What it does |
|---|---|---|
| 01 | 01-create-redis.sh |
Provision Redis, seed the marker on the master |
| 02 | 02-create-backupjob.sh |
BackupJob (backupClassName: cozy-default) → RDB dump to S3 |
| 03 | 03-restore-in-place.sh |
Corrupt the marker, RestoreJob back into the source, assert it returns |
| 04 | 04-restore-to-copy.sh |
RestoreJob with targetApplicationRef into a fresh copy, assert the marker landed |
Notes
- Master discovery goes through the operator's sentinel Service
rfs-redis-<name>(master namemymaster), so writes and the dump/replay always target the current master even after a failover. - Faithful restore. The restore loads the RDB into a throwaway local redis and replays what a real engine emits, so all logical databases (
SELECTper db), stream last-ids and consumer groups survive — a merge onto db0 does not happen. - Endpoint TLS. The projected
endpointincozy-backups-credsis always scheme-stripped, so the strategy prependshttps://and the transport is always TLS (there is nohttp://path). It verifies against the image's system CA store by default — the platform bucket's ACME cert needs nothing more — honours a private CA frombackupStorage.endpointCASecretNamewhen set, and skips verification only whenbackupStorage.insecureSkipTLSVerify: trueis set explicitly. - No PITR. RDB is a discrete snapshot; the engine ships no continuous log to replay to an arbitrary time, so
spec.options.recoveryTimeis not supported (the etcd-like case).