mirror of
https://github.com/cozystack/cozystack.git
synced 2026-10-30 00:27:04 +09:00
Aleksei Sviridkin
04d469fc85
The backup round-trips drive examples/backups, whose bucket waits gave up at 300s and whose postgres waits at 360s, under the 600s install timeout cozystack-api gives each of those releases. The kafka example's bucket wait passed no budget and took the helper's 300s default. A failed install there reported only that the wait ran out. Raise each to 660s, and grow the Chainsaw op around every walkthrough by what its waits gained, so a failure at any later wait keeps the headroom it had and is still reported by the script rather than cut off by the op. The kafka and kafka-metadata Kafka waits stay: their 7h install timeout cannot be cleared inside the E2E job cap. 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).