mirror of
https://github.com/cozystack/cozystack.git
synced 2026-10-30 08:37:31 +09:00
Andrey Kolkov
1289f522fa
Store the Redis strategy Template schemaless, as the Rabbitmq strategy already does: without the markers controller-gen emitted the full PodTemplateSpec schema and the CRD reached ~602 KB, pushing the chart's Helm-release Secret past the 1 MiB cap so backupstrategy-controller failed to install at all. Give the example strategy a cleanup branch, and both scripts an explicit `elif restore` / `else exit 1`, so a deleted Backup rendered with Mode=cleanup deletes its object instead of falling into the restore path and FLUSHALLing the live master. Forward a backupStrategyController block through the platform bundle alongside backupStorage, so redisBackupResources — the restore-Pod sizing knob the loader-not-ready message points at — is reachable via spec.components.platform.values.backupStrategyController, not merely settable on a Helm-managed Strategy CR that reverts on the next upgrade. Correct the endpointCASecretName doc row to match the now-optional mount, and `int` the activeDeadlineSeconds interpolation so a large values-file override renders as an integer, not exponent form. Assisted-By: LLM Signed-off-by: Andrey Kolkov <androndo@gmail.com>
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).