mirror of
https://github.com/cozystack/cozystack.git
synced 2026-10-23 03:27:50 +09:00
Andrey Kolkov
43b02bda30
The Redis backup demo now takes APP_KIND=Valkey, which switches the app kind and the chart prefix the helpers derive sentinel and Secret names from. The demo BackupClass routes Valkey to the same demo strategy. The valkey suite gains valkey-backup-roundtrip, which drives that demo end to end: seed a marker, back it up, restore it in place and into a copy. It writes to tenant-root's seaweedfs through seaweedfs-s3, so a seaweedfs change now selects the valkey suite too, and since the round-trip runs examples/backups/redis as its harness, an edit there selects both the redis and the valkey suites. The reduced E2E install keeps the backup stack for the valkey suite, as it does for the other backup round-trip suites. Signed-off-by: Andrey Kolkov <androndo@gmail.com> Assisted-By: LLM
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
- Valkey.
APP_KIND=Valkeyruns the same walkthrough against a Valkey app, which runs on the same RedisFailover operator; everyredis-<name>resource below is thenvalkey-<name>. - 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).