Install and secure Redis with ACLs, TLS, persistence and verified backups
Deploy Redis Open Source 8.8 on Ubuntu 24.04 with correct product and licensing terminology, TLS-only private access, named least-privilege ACL users, AOF/RDB durability and a checksum-backed isolated restore drill.
Operate a self-managed Redis server whose network, identity, durability and recovery guarantees are explicit and behaviorally verified without exposing credentials or pretending a local persistence file is a tested backup.
- Redis Open Source 8.8.x latest approved patch
- Ubuntu Server 24.04 LTS
- OpenSSL 3.x distribution-supported
- License approval Legal approval for the selected Redis Open Source 8 tri-license option: AGPLv3, RSALv2 or SSPLv1.
- Private host Ubuntu 24.04 LTS host with private DNS/IP, firewall, time sync, capacity and no public Redis exposure.
- PKI CA-issued server certificate/key and CA bundle whose SAN matches {{redisHost}}, plus a tested rotation owner.
- Data contract Per-namespace classification, TTL, memory, eviction, RPO, RTO, retention and application validation.
- Secret delivery Approved secret manager or protected file workflow for named ACL credentials without argv/history/repository exposure.
- Recovery environment Encrypted off-host repository and isolated compatible restore host or namespace with enough capacity.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A self-managed Redis Open Source 8.8 deployment on Ubuntu 24.04 LTS, built or installed from a verified official artifact with a documented tri-license choice, running as a dedicated unprivileged service account and listening only on a private address through TLS.
- An explicit ACL file with the default user disabled, separate application, replication, backup and break-glass administrative users, key and Pub/Sub channel patterns, command categories and a password-delivery workflow that keeps plaintext secrets out of configuration repositories, process lists, shell history and routine logs.
- A persistence and recovery design that combines AOF with `appendfsync everysec`, periodic RDB checkpoints, isolated filesystem permissions, bounded memory and eviction behavior, monitored background save/rewrite health, encrypted off-host backup copies, deterministic restore fixtures and a measured restore drill.
- Unauthenticated, plaintext and unauthorized commands fail; the application identity can access only its documented key/channel namespace; operational identities cannot modify ACLs or configuration; the emergency administrator is disabled or tightly controlled outside routine use.
- TLS certificate chain and hostname validation succeed for clients, TLS applies to every exposed connection, the non-TLS port is disabled, private keys are readable only by the Redis service, and certificate expiry plus rotation have owners.
- AOF and RDB persistence state is healthy, a verified RDB backup is copied from a stable snapshot rather than a live changing file, an isolated replacement instance restores the expected dataset and TTL behavior, and RPO/RTO evidence is current.
Architecture
How the parts fit together
One Redis Open Source 8.8 server runs on a private host behind a firewall and accepts only TLS. Redis 8 and later is the current product named Redis Open Source and is tri-licensed under AGPLv3, RSALv2 or SSPLv1; this guide does not call it Redis Community Edition, which refers to the 7.4 line. A dedicated operating-system user owns the data directory and runtime files. Redis loads a separate ACL file whose secrets are provisioned by an approved secret workflow rather than committed with the main configuration. The application uses a named ACL user restricted by command categories, explicit denials and key/channel patterns. AOF supplies near-real-time durability according to fsync policy, while RDB snapshots provide compact restore points; neither protects against host loss until a completed snapshot is copied, integrity-checked, encrypted and retained off host. Monitoring covers latency, rejected connections, ACL denials, memory, eviction, fork and copy-on-write pressure, RDB/AOF status, disk space, certificate expiry and backup/restore evidence. This is a single-node durability design, not high availability; Sentinel is addressed separately.
- Classify Redis as cache, reconstructible state or system of record; define RPO, RTO, maximum memory, eviction, latency, durability and data-loss acceptance before selecting persistence.
- Review Redis Open Source 8.8 licensing and support, verify the official artifact, operating-system compatibility, CPU/memory/disk capacity, kernel settings and private network boundary.
- Provision CA-issued TLS material and service-account filesystem permissions, author the server configuration and a separately managed ACL file, then validate syntax in an isolated instance.
- Start Redis with plaintext disabled, private binding, supervised service management, AOF and RDB enabled, dangerous administrative commands absent from application ACLs, and stable disk paths.
- Test authentication and authorization with each identity, including negative commands, key namespaces and Pub/Sub channels. Rotate a test credential without disconnecting the only recovery identity.
- Write a deterministic fixture with hashes, TTLs, lists and streams, force and inspect persistence, copy only a completed RDB or coordinated AOF set, checksum and encrypt it off host.
- Restore to an isolated compatible Redis Open Source release, verify data types, counts, values, TTL expectations and application semantics, then record measured RPO and RTO.
- Operate certificate rotation, ACL review, memory/eviction, persistence errors, disk capacity, fork latency, backup retention, upgrades and replacement through repeatable change control.
Assumptions
- Redis Open Source 8.8.0, released as GA in May 2026, is the current feature line used by this guide. Administrators install the latest security and reliability patch available in the approved 8.8 line rather than pinning indefinitely to 8.8.0.
- Redis 8 and later is named Redis Open Source and offers AGPLv3, RSALv2 and SSPLv1 license choices. Redis Community Edition is the official name for the 7.4 line; Redis Software and Redis Cloud are different proprietary or managed products.
- Ubuntu Server 24.04 LTS is the reference host. The organization can build Redis with `BUILD_TLS=yes` from an official signed or digest-verified release, or use an official Redis package that includes TLS support.
- The host has a private DNS name included in the server certificate SAN, a stable private address, synchronized time, an approved firewall and no direct Internet exposure on any Redis or management port.
- A private CA or approved public/internal CA issues the server and optional client certificates. Private keys, CA keys and passphrases are not created by this tutorial or stored in the repository.
- Redis runs as a non-root dedicated user. Data, log, run, TLS and ACL paths have explicit ownership and the service cannot write arbitrary application or web directories.
- The dataset size, write rate, fork copy-on-write peak, disk bandwidth, AOF rewrite amplification, RDB duration, memory fragmentation and restore time have been measured on representative load.
- The application supports Redis ACL usernames, TLS CA validation, certificate hostname validation, reconnect behavior, authentication rotation and the selected key/channel namespace.
- The backup repository is encrypted, versioned or immutable as required, independently authorized, monitored and able to retain Redis data for the approved period.
- A standalone Redis server can be unavailable during host or process failure. This guide intentionally does not claim HA; Redis Sentinel or another topology is a separate architecture.
- AOF, RDB, replication and backups protect different failure modes. Replication copies mistakes; persistence stores local history; only tested off-host restore evidence proves recoverability.
- No command in this guide accepts a real password as a shell argument. Interactive prompts, protected files, file descriptors or a secrets agent supply credentials.
Key concepts
- Redis Open Source
- The official Redis 8+ self-managed product name. It replaces the split Redis Stack experience and is available under the AGPLv3, RSALv2 or SSPLv1 tri-license choices.
- ACL user
- A named Redis authentication identity with rules controlling passwords, command categories and subcommands, key patterns and Pub/Sub channel patterns.
- Default user
- The compatibility ACL identity used when clients authenticate with only a password or no username. Disabling it forces named identity use and avoids shared legacy access.
- AOF
- Append-only persistence that logs write operations. Durability depends on fsync policy, OS and storage behavior; rewrite compacts history and creates temporary resource pressure.
- RDB
- A compact point-in-time snapshot produced by forked background save. It is useful for backup and restart but loses changes after the snapshot when used alone.
- Hybrid persistence
- Using both AOF and RDB, including RDB preamble in rewritten AOF. On restart Redis generally uses AOF when enabled because it is expected to be more complete.
- Eviction policy
- The behavior when `maxmemory` is reached. Eviction can be acceptable for cache keys but is data loss for durable state; `noeviction` rejects writes instead.
- Copy-on-write
- Additional memory pages created while a forked RDB or AOF rewrite child observes the dataset and the parent continues writes. Peak memory can exceed steady-state use.
- TLS client authentication
- Redis TLS normally requires valid client certificates by default. Setting `tls-auth-clients no` uses server-only TLS and leaves client identity to ACL credentials.
- Backup verification
- Checking artifact completeness, checksum, encryption and retention before restoring it into an isolated compatible instance and validating application-level data.
Before you copy
Values used in this guide
{{redisVersion}}Approved Redis Open Source 8.8 patch.
Example: 8.8.0{{redisHost}}Private DNS name present in the TLS SAN.
Example: redis01.internal.example{{redisPrivateIp}}Stable private listener address.
Example: 10.60.10.11{{redisPort}}TLS listener port.
Example: 6379{{redisConfig}}Primary server configuration path.
Example: /etc/redis/redis.conf{{redisAclFile}}Separately protected ACL file path.
Example: /etc/redis/users.acl{{redisDataDir}}Persistent Redis data directory.
Example: /var/lib/redis{{redisTlsCert}}Server certificate chain path.
Example: /etc/redis/tls/redis.crt{{redisTlsKey}}secretServer private key path.
Example: /etc/redis/tls/redis.key{{redisTlsCa}}Trusted CA certificate bundle path.
Example: /etc/redis/tls/ca.crt{{appUser}}Named least-privilege application ACL user.
Example: orders-api{{appKeyPattern}}Application key namespace rule.
Example: orders:*{{appChannelPattern}}Application Pub/Sub channel rule.
Example: orders-events:*{{memoryLimit}}Capacity-tested Redis maxmemory value.
Example: 6gb{{backupDirectory}}Root-only local staging directory.
Example: /srv/redis-backup-stage{{backupArtifact}}Dated completed RDB backup file.
Example: redis01-20260728T020000Z.rdb{{restorePort}}Loopback-only isolated restore port.
Example: 6389{{expectedDigest}}SHA-256 recorded after stable snapshot copy.
Example: e4f4...full-reviewed-digestSecurity and production boundaries
- Never expose Redis directly to the Internet. ACLs and TLS are defense layers inside a trusted network, not justification for a public listener.
- Select the Redis 8 tri-license with legal review. Do not describe RSALv2 or SSPLv1 as OSI-approved; AGPLv3 is the OSI-approved option in the official tri-license.
- Disable the default user and use named ACL users. Avoid one shared password because attribution, least privilege and rotation become impossible.
- Do not put ACL plaintext passwords in Git, images, shell history, command arguments, process environment dumps or support tickets. Protect the ACL file like a credential store.
- Application users must not receive `CONFIG`, `ACL`, `MODULE`, `DEBUG`, `SHUTDOWN`, replication, persistence or broad scripting privileges unless a specific reviewed feature requires them.
- Key patterns restrict command key arguments but not every possible information channel. Review modules, scripting, Pub/Sub patterns and commands whose arguments are not keys.
- Use CA and hostname validation. Do not deploy `--insecure`, skip certificate validation or keep plaintext enabled during normal operation.
- Keep the TLS private key readable only by Redis and the certificate deployment mechanism. Test rotation before expiry and alert well in advance.
- AOF `everysec` may lose approximately one second of acknowledged writes under failure. `always` has different latency and storage tradeoffs; no setting bypasses hardware failure semantics.
- RDB and AOF can contain the entire dataset, including secrets and personal data. Encrypt, restrict, audit and expire backup artifacts accordingly.
- Never copy a live RDB while it is being replaced or an incomplete AOF multipart set. Trigger or observe a completed persistence point and copy atomically from stable files.
- Do not run Redis as root and do not rely on renaming commands as an authorization control. ACL denial and operating-system containment are the controls.
Stop before continuing if
- Stop if the license choice, official artifact or version support is not approved.
- Stop if Redis would listen on a public address or firewall permits untrusted networks.
- Stop if TLS certificate SAN, chain, expiry or private-key permissions fail.
- Stop if the default ACL user remains enabled or the application requires a shared administrator credential.
- Stop if application ACL needs unrestricted commands, keys or channels without a documented reason.
- Stop if maxmemory, eviction behavior and dataset growth are unknown.
- Stop if disk free space cannot sustain simultaneous AOF rewrite, RDB save and backup staging.
- Stop if `rdb_last_bgsave_status` or `aof_last_bgrewrite_status` is not `ok`.
- Stop if any backup is copied without stable-completion evidence and a checksum.
- Stop if restore requires a different incompatible major version or cannot meet RPO/RTO.
- Stop if real passwords or private keys appear in commands, logs, repository or ticket output.
- Stop production onboarding until negative ACL, plaintext, invalid-certificate and unauthorized-network tests pass.
instruction
Classify the dataset and approve Redis 8 licensing
Document whether every key is cache, reconstructible state or authoritative data; define RPO, RTO, retention, maximum memory, eviction and outage tolerance. Record the selected Redis Open Source 8 tri-license before downloading software.
Why this step matters
Persistence, eviction and backup decisions are unsafe until the owner defines what data loss means. Redis may be a disposable cache in one application and an authoritative queue or session store in another. The Redis 8 product and license terminology also matters: Redis Open Source is tri-licensed, while Redis Community Edition refers to 7.4 and Redis Cloud/Software are different offerings.
What to understand
Map each key prefix and stream to owner, source of truth, TTL, write rate, maximum size and restore validation. Decide whether eviction is acceptable per namespace; one instance-wide maxmemory policy cannot express contradictory durability requirements safely.
Legal must select AGPLv3, RSALv2 or SSPLv1 for Redis Open Source 8. AGPLv3 is the OSI-approved open-source option; RSALv2 and SSPLv1 are source-available choices with distinct obligations.
Model acknowledged-write loss for AOF everysec, point-in-time loss for RDB, total host failure, operator deletion, credential compromise and backup-repository loss.
System changes
- No service state changes; produces an approved data, licensing and recovery contract.
Syntax explained
RPO- Maximum tolerated data loss measured from the last usable recovery point.
RTO- Maximum elapsed time from incident declaration to a validated usable service.
Redis data contract Product: Redis Open Source 8.8 License option: AGPLv3 (approved by legal) Dataset: reconstructible sessions plus durable rate limits RPO: 1 second for durable namespace RTO: 30 minutes Eviction: noeviction Backup retention: 35 days
Checkpoint: Verify this layer before continuing
Continue whenEvery namespace has classification, owner, TTL, eviction decision, RPO/RTO and validation; legal approves the exact Redis Open Source license option.
Stop whenStop if authoritative and evictable data share an unreviewed policy, or licensing and backup ownership are unresolved.
If this step fails
Stakeholders request both aggressive eviction and zero data loss.
Likely causeThe same instance mixes cache and durable state without an explicit capacity and namespace design.
Review key-prefix inventory and peak memory telemetry.
ResolutionSeparate incompatible workloads or select noeviction and capacity for the durable contract; document the unavoidable tradeoff.
Security notes
- Do not copy production key names or values into planning documents; they can contain personal data or secrets.
Alternatives
- Use separate Redis instances for materially different durability, security or eviction requirements.
Stop conditions
- Stop if authoritative and evictable data share an unreviewed policy, or licensing and backup ownership are unresolved.
command
Verify the official Redis Open Source artifact and TLS build
Download the approved 8.8 patch from the official release location, verify its published digest, build with TLS support and record binary version plus linkage. Never replace the running binary before staging tests pass.
Why this step matters
Version and provenance determine security support, persistence compatibility and available ACL/TLS behavior. Redis 8.8.0 is the current GA feature release identified in official release notes as of the guide date; production should consume the latest approved 8.8 patch. TLS support can be compile-time, so a version string alone is insufficient.
What to understand
Verify the release archive against an official published hash or reproducible organization package manifest before compilation. Preserve source tag, digest, compiler, OpenSSL and package build metadata.
Build and test in a clean pipeline rather than on the production host. Do not run Redis test certificates or sample keys in production.
System changes
- No runtime change; inspects the staged or currently installed binaries.
Syntax explained
BUILD_TLS=yes- Compiles Redis and redis-cli with OpenSSL TLS support.
redis-server --version- Reports product version and build attributes but not artifact authenticity.
redis-server --version && redis-cli --version && ldd "$(command -v redis-server)" | grep -E 'ssl|crypto'Redis server v=8.8.0 sha=00000000:0 malloc=jemalloc-5.3.0 bits=64 build=<redacted> redis-cli 8.8.0 libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3
Checkpoint: Verify this layer before continuing
Continue whenServer and CLI are the approved latest Redis Open Source 8.8 patch, artifact digest is recorded and TLS libraries are present.
Stop whenStop on unknown provenance, version mismatch, unsupported OS, failed tests or missing TLS support.
If this step fails
The package manager offers Redis 7.x instead of 8.8.
Likely causeUbuntu distribution repositories lag the approved Redis Open Source feature line or package names refer to a different product.
apt-cache policy redis-servercommand -v redis-serverredis-server --version
ResolutionInstall the reviewed official Redis package or build verified source in the pipeline; do not mix binaries and configuration from different lines.
Security notes
- Treat build workers and package repositories as supply-chain trust boundaries; use signatures/digests and least-privilege publishing.
Alternatives
- Remain on an actively supported earlier Redis line only through a documented compatibility and security exception.
Stop conditions
- Stop on unknown provenance, version mismatch, unsupported OS, failed tests or missing TLS support.
command
Prepare the service account, directories and TLS material
Create dedicated data, runtime, log and TLS paths with restrictive ownership. Install only the server certificate, private key and CA bundle supplied by the approved PKI workflow; never generate a production CA on the Redis host.
Why this step matters
Redis must not run as root or write outside its dedicated paths. The TLS private key needs service readability but must not be readable by other users. PKI lifecycle is separate from Redis: hostname, chain, key usage, expiry and revocation must be correct before the service is exposed.
What to understand
Use `namei -l` to check every parent directory; a secure file mode does not help when an ancestor is writable by an untrusted group. Verify the certificate and key match without printing private material.
Keep data and backup staging on filesystems sized for AOF rewrite, RDB generation and copy-on-write. Runtime paths may be tmpfs and must be recreated by systemd.
System changes
- Creates service directories and installs TLS files; no Redis listener starts.
Syntax explained
0640 root:redis- Allows root to manage and the Redis group to read while denying all other users.
0750- Allows directory traversal only to owner and group, with no other-user access.
Values stay on this page and are never sent or saved.
sudo install -d -o redis -g redis -m 0750 {{redisDataDir}} /run/redis /var/log/redis && sudo install -d -o root -g redis -m 0750 /etc/redis/tls && sudo install -o root -g redis -m 0640 <staged-cert> {{redisTlsCert}} && sudo install -o root -g redis -m 0640 <staged-key> {{redisTlsKey}} && sudo install -o root -g redis -m 0644 <staged-ca> {{redisTlsCa}}drwxr-x--- redis redis /var/lib/redis drwxr-x--- root redis /etc/redis/tls -rw-r----- root redis /etc/redis/tls/redis.crt -rw-r----- root redis /etc/redis/tls/redis.key -rw-r--r-- root redis /etc/redis/tls/ca.crt Certificate SAN: DNS:redis01.internal.example Not After: Oct 26 00:00:00 2026 GMT
Checkpoint: Verify this layer before continuing
Continue whenRedis is unprivileged, paths are not broadly writable/readable, certificate SAN matches {{redisHost}}, chain validates and key matches certificate.
Stop whenStop if the key is world-readable, certificate is expired/mismatched, CA provenance is unknown or storage capacity is insufficient.
If this step fails
Redis logs Permission denied for the TLS key.
Likely causeFile group, mode, parent traversal, AppArmor/SELinux policy or systemd sandbox blocks access.
namei -l {{redisTlsKey}}sudo -u redis test -r {{redisTlsKey}}journalctl -u redis-server -n 50
ResolutionCorrect the narrow ownership/policy path; do not make the private key world-readable or run Redis as root.
Security notes
- Never display the private key, CA key or key passphrase. Rotate immediately if copied into logs or tickets.
Alternatives
- Use a secrets/PKI agent with atomic file rotation and service notification instead of manual installation.
Stop conditions
- Stop if the key is world-readable, certificate is expired/mismatched, CA provenance is unknown or storage capacity is insufficient.
config
Author the private TLS and persistence configuration
Create a reviewed redis.conf with plaintext disabled, private binding, protected mode, separate ACL file, bounded memory, no eviction for durable data, AOF everysec and RDB checkpoints. Adapt paths and capacity from testing.
Why this step matters
The configuration makes every durability and exposure choice visible. `port 0` prevents accidental plaintext use; TLS remains server-authenticated while ACL handles client identity because `tls-auth-clients no` is explicit. AOF everysec balances latency and a roughly one-second loss window, while RDB creates compact recovery points.
What to understand
Mutual TLS is stronger for machine identity when clients can manage certificates; leaving the default client-certificate requirement enabled then requires every application, replication and operational client to present a valid certificate.
`noeviction` rejects writes at maxmemory instead of silently deleting durable keys. Capacity and alerts must prevent sustained errors. For a pure cache, a reviewed allkeys policy may be appropriate.
AOF rewrite uses a multipart directory in modern Redis. Backups must preserve the manifest and referenced files coherently if AOF is copied; the primary drill uses a completed RDB for simpler atomic recovery.
System changes
- Writes desired server configuration but does not restart Redis.
Syntax explained
port 0- Disables the non-TLS TCP listener.
appendfsync everysec- Requests AOF fsync approximately every second, allowing a bounded but non-zero loss window.
stop-writes-on-bgsave-error yes- Rejects writes when configured RDB persistence cannot complete, surfacing durability failure.
{{redisConfig}}Values stay on this page and are never sent or saved.
bind {{redisPrivateIp}} 127.0.0.1
protected-mode yes
port 0
tls-port {{redisPort}}
tls-cert-file {{redisTlsCert}}
tls-key-file {{redisTlsKey}}
tls-ca-cert-file {{redisTlsCa}}
tls-auth-clients no
aclfile {{redisAclFile}}
supervised systemd
daemonize no
dir {{redisDataDir}}
dbfilename dump.rdb
appendonly yes
appenddirname appendonlydir
appendfsync everysec
aof-use-rdb-preamble yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
maxmemory {{memoryLimit}}
maxmemory-policy noeviction
logfile /var/log/redis/redis-server.log
pidfile /run/redis/redis-server.pidConfiguration review Private bind: PASS Plaintext port: disabled TLS port: 6379 ACL file: separate AOF: yes / everysec RDB: 900/1, 300/10, 60/10000 Stop writes on save error: yes Eviction: noeviction
Checkpoint: Verify this layer before continuing
Continue whenPeer review confirms private binding, TLS-only, correct paths, persistence/RPO, maxmemory/eviction and no secret values.
Stop whenStop if config exposes all interfaces, enables plaintext, embeds passwords or chooses persistence/eviction without owner approval.
If this step fails
Redis reports a configuration directive is invalid.
Likely causeThe running binary version, path syntax or included configuration differs from the reviewed Redis 8.8 reference.
redis-server {{redisConfig}} --test-memory 64redis-server --version
ResolutionValidate with the exact staged binary and official self-documented redis.conf; correct the reviewed file before service restart.
Security notes
- Configuration is sensitive because it exposes filesystem and network design; do not put credentials in it.
Alternatives
- Use mutual TLS by omitting `tls-auth-clients no` when every client can present an approved certificate.
Stop conditions
- Stop if config exposes all interfaces, enables plaintext, embeds passwords or chooses persistence/eviction without owner approval.
config
Create named ACL users without shared administration
Render the ACL file through a secret workflow. Disable default, restrict the application to required commands and namespaces, define a replication/backup user separately, and keep break-glass admin offline or disabled until approved use.
Why this step matters
Named users give attribution, scoped authorization and independent rotation. Starting from `-@all` then adding required commands is safer than subtracting a few dangerous commands from full access. Key and channel patterns constrain application data, while an offline break-glass identity avoids making the normal operator omnipotent.
What to understand
Redis ACL `#hash` stores a SHA-256 password hash rather than plaintext, but the original high-entropy secret remains sensitive in client configuration. Generate and distribute it outside this file workflow.
Command categories evolve across Redis versions. Review effective rules and `ACL DRYRUN` after upgrades. Scripts and modules can widen behavior; deny them unless explicitly required and tested.
The backup user example can initiate BGSAVE but cannot fetch filesystem files through Redis. Off-host copying still occurs under a separate OS/repository identity.
System changes
- Creates or replaces the protected ACL policy file; it changes access after service start or ACL LOAD.
Syntax explained
-@all- Removes all command categories before allowlisting only required operations.
~{{appKeyPattern}}- Restricts key arguments to the application namespace.
&{{appChannelPattern}}- Restricts Pub/Sub channel access to the approved pattern.
{{redisAclFile}}Values stay on this page and are never sent or saved.
user default off
user {{appUser}} on #<sha256-password-hash> resetkeys resetchannels -@all +@read +@write +@connection -CONFIG -ACL -MODULE -DEBUG -SHUTDOWN -EVAL -EVALSHA ~{{appKeyPattern}} &{{appChannelPattern}}
user backup-reader on #<sha256-password-hash> resetkeys resetchannels -@all +PING +INFO +BGSAVE +LASTSAVE +ROLE +CLIENT|ID ~* &*
user breakglass-admin off #<sha256-password-hash> allkeys allchannels +@allACL file validation default: off orders-api: on, scoped commands, keys orders:*, channels orders-events:* backup-reader: persistence inspection only breakglass-admin: off File mode: 0640 root:redis
Checkpoint: Verify this layer before continuing
Continue whenDefault and break-glass users are off, application rules pass expected DRYRUN checks and deny admin, unrelated keys and channels.
Stop whenStop if plaintext secrets are present, application needs +@all/allkeys/allchannels or no independent recovery identity exists.
If this step fails
ACL file loads but application authentication fails.
Likely causePassword hash, username, rule order, client AUTH form or rendered secret differs from application configuration.
sudo -u redis grep -n '^user ' {{redisAclFile}}redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} ACL LOG 10
ResolutionValidate the username and secret through the protected delivery path, use a temporary dual credential if rotating and never weaken the rules globally.
Security notes
- ACL files and hashes are credentials. Restrict backups and never include real values in code review output.
Alternatives
- Use an external secret agent and two named rotating users per application when zero-downtime credential rotation is required.
Stop conditions
- Stop if plaintext secrets are present, application needs +@all/allkeys/allchannels or no independent recovery identity exists.
command
Start the service and verify TLS-only private listening
Validate the systemd unit, start Redis in a controlled window and inspect listener address, process identity and logs. Test valid TLS, plaintext failure, invalid CA failure and unauthenticated failure.
Why this step matters
Service startup is the first point at which network and persistence settings become active. Listener inspection proves the intended private address and absence of plaintext. Negative tests demonstrate that transport and authentication fail closed rather than relying on a successful privileged connection.
What to understand
Run connection tests from an approved client network and a controlled unauthorized host. The host firewall must allow only named application and management sources.
Systemd should set User/Group, no-new-privileges and appropriate filesystem protections without blocking Redis data, logs, TLS and runtime paths. Validate the actual unit and drop-ins.
System changes
- Starts and enables the Redis service, opens the private TLS listener and may initialize AOF/RDB files.
Syntax explained
enable --now- Starts the unit immediately and enables it for future boots.
ss -lntp- Shows effective listening sockets and owning process.
Values stay on this page and are never sent or saved.
sudo systemctl daemon-reload && sudo systemctl enable --now redis-server && sudo systemctl --no-pager --full status redis-server && sudo ss -lntp | grep ':{{redisPort}}'Active: active (running)
Main PID: 2184 (redis-server)
User: redis
LISTEN 0 511 10.60.10.11:6379 0.0.0.0:* users:(("redis-server",pid=2184,fd=6))
Plaintext PING: connection reset
TLS with wrong CA: certificate verify failed
TLS unauthenticated PING: NOAUTH Authentication requiredCheckpoint: Verify this layer before continuing
Continue whenRedis runs as redis, only private TLS port listens, plaintext/wrong-CA/unauthenticated/unapproved-network tests fail.
Stop whenStop if any public or plaintext listener exists, process runs as root, logs expose secrets or persistence initializes in the wrong path.
If this step fails
Service enters restart loop.
Likely causeConfiguration, ACL, TLS path, permissions, port conflict, memory or persistence file prevents startup.
systemctl status redis-server --no-pagerjournalctl -u redis-server -n 100 --no-pagersudo -u redis redis-server {{redisConfig}} --test-memory 64
ResolutionStop retries, diagnose the first error, correct the staged configuration and preserve existing data; do not delete persistence files.
Security notes
- Journal output may contain client addresses and key metadata. Redact before sharing and verify no secrets are logged.
Alternatives
- Run a loopback-only parallel validation instance on {{restorePort}} before changing the production unit.
Stop conditions
- Stop if any public or plaintext listener exists, process runs as root, logs expose secrets or persistence initializes in the wrong path.
verification
Prove ACL positive and negative behavior
Authenticate the application client through a protected prompt or client credential provider. Exercise required reads/writes plus denied admin commands, unrelated keys, unrelated channels and unauthenticated access.
Why this step matters
ACL correctness is behavioral. The rule text can appear narrow while modules, scripts, subcommands or client key construction create unexpected access. Positive tests prevent a secure configuration from breaking the application, and negative tests prove cross-namespace and administrative denial.
What to understand
Use `ACL DRYRUN` with the administrator for coverage without changing data, then execute a deterministic fixture under the application identity. Avoid production customer keys.
Inspect `ACL LOG` for denied operations after a bounded canary. Repeated denials may indicate missing legitimate commands or probing; do not automatically grant from logs.
System changes
- Creates only non-sensitive test keys/channels in the approved namespace and ACL audit entries.
Syntax explained
--askpass- Prompts without placing the password in argv or shell history.
ACL WHOAMI- Returns the authenticated named user, confirming identity selection.
Values stay on this page and are never sent or saved.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} --user {{appUser}} --askpass ACL WHOAMIEnter password: [hidden] "orders-api" SET orders:test value: OK GET orders:test: "value" GET unrelated:test: NOPERM this user has no permissions to access one of the keys CONFIG GET '*': NOPERM this user has no permissions to run the 'config|get' command SUBSCRIBE unrelated: NOPERM this user has no permissions to access one of the channels
Checkpoint: Verify this layer before continuing
Continue whenRequired operations succeed; unauthenticated, admin, unrelated key/channel, scripting and module operations fail with NOAUTH/NOPERM.
Stop whenStop if any forbidden operation succeeds or the application requires break-glass credentials.
If this step fails
ACL negative tests succeed unexpectedly.
Likely causePattern is broad, user inherited `+@all`, default user is active or the client authenticated as another identity.
ACL GETUSER {{appUser}}ACL WHOAMIACL LOG 20
ResolutionBlock production access, correct the ACL source, reload in a controlled session and repeat every positive/negative fixture.
Security notes
- Do not include the password in URI, `-a`, environment capture or transcript. Treat ACL LOG key/channel details as sensitive.
Alternatives
- Use mTLS client certificates plus ACL usernames when machine certificate lifecycle is mature.
Stop conditions
- Stop if any forbidden operation succeeds or the application requires break-glass credentials.
command
Create a deterministic persistence fixture
Write non-sensitive keys of several data types with a long TTL under the application user, record expected values and trigger a background save through the backup identity. Observe completion rather than copying immediately.
Why this step matters
A deterministic fixture allows restore verification without customer data. Multiple data types and TTLs detect incomplete, wrong-database or stale restores better than a single key. `BGSAVE SCHEDULE` avoids colliding with another persistence operation, but completion must be observed through INFO before backup.
What to understand
Include string, hash, list, set, sorted set and stream records plus one expiring key. Record creation time and expected TTL range so time elapsed during backup/restore is interpreted correctly.
BGSAVE forks the process and can cause memory/latency pressure. Run only after capacity validation and monitor copy-on-write and disk.
System changes
- Writes non-sensitive fixture data and schedules an RDB snapshot in the production data directory.
Syntax explained
--pipe- Streams RESP commands efficiently and reports replies/errors without embedding a secret.
BGSAVE SCHEDULE- Schedules a background save after an active persistence operation completes.
Values stay on this page and are never sent or saved.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} --user {{appUser}} --askpass --pipe < redis-restore-fixture.resp && redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} --user backup-reader --askpass BGSAVE SCHEDULEFixture commands processed: 8 errors: 0 Background saving scheduled rdb_bgsave_in_progress:0 rdb_last_bgsave_status:ok rdb_last_save_time:1785204000 aof_enabled:1 aof_last_write_status:ok aof_last_bgrewrite_status:ok
Checkpoint: Verify this layer before continuing
Continue whenFixture values/counts are recorded, BGSAVE completes with status ok, AOF write/rewrite status is ok and persistence timestamps advance.
Stop whenStop on latency breach, memory pressure, save/rewrite error, disk alert or fixture command error.
If this step fails
BGSAVE returns Background save already in progress.
Likely causeAn RDB save or AOF rewrite child is already active.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO persistence
ResolutionUse SCHEDULE or wait for the active operation to complete; do not launch competing fork-heavy jobs.
Security notes
- Fixture must contain synthetic data only; a backup snapshot still contains the complete production dataset.
Alternatives
- Trigger a backup from a replica to reduce primary fork impact only after accepting replica lag and verifying the replica is current.
Stop conditions
- Stop on latency breach, memory pressure, save/rewrite error, disk alert or fixture command error.
command
Stage, verify and transfer a completed backup
After LASTSAVE and persistence status confirm completion, copy dump.rdb to a root-only staging name, calculate checksums, run redis-check-rdb and upload through the encrypted repository workflow. Never copy the temporary RDB.
Why this step matters
The completed `dump.rdb` is atomically replaced by Redis, so copying it after successful BGSAVE provides a stable artifact. Local validation detects gross corruption before transfer. A checksum identifies exact bytes but does not prove logical or application recovery; the next isolated restore supplies that evidence.
What to understand
The staging copy contains the full dataset and must be root-only, short-lived and on encrypted storage. Upload it with a dedicated repository identity that cannot alter Redis or read unrelated backups.
Record source host, Redis version, LASTSAVE, artifact size, digest, repository version/retention and configuration revision without including key names or values.
System changes
- Creates a local sensitive backup copy and, through the external workflow, an encrypted off-host backup version.
Syntax explained
--reflink=auto- Uses copy-on-write cloning when the filesystem safely supports it, otherwise performs a normal copy.
redis-check-rdb- Parses RDB structure and checksum but does not perform application-level validation.
Values stay on this page and are never sent or saved.
sudo install -d -o root -g root -m 0700 {{backupDirectory}} && sudo cp --reflink=auto --preserve=mode,timestamps {{redisDataDir}}/dump.rdb {{backupDirectory}}/{{backupArtifact}} && sudo redis-check-rdb {{backupDirectory}}/{{backupArtifact}} && sudo sha256sum {{backupDirectory}}/{{backupArtifact}}[offset 0] Checking RDB file /srv/redis-backup-stage/redis01-20260728T020000Z.rdb [offset 27] AUX FIELD redis-ver = '8.8.0' [offset 12843] Checksum OK [info] 8 keys read [info] 0 expires [info] 0 already expired e4f4c0a1... redis01-20260728T020000Z.rdb
Checkpoint: Verify this layer before continuing
Continue whenStable snapshot validates, SHA-256 is recorded, encrypted off-host object is immutable/versioned and local staging is removed after verification.
Stop whenStop if source save status is not ok, checksum changes, validation fails, repository encryption/ownership is unknown or retention is missing.
If this step fails
redis-check-rdb reports checksum mismatch.
Likely causeArtifact is incomplete, copied during replacement, corrupted in storage or not an RDB file.
stat {{backupDirectory}}/{{backupArtifact}}sha256sum {{backupDirectory}}/{{backupArtifact}}
ResolutionQuarantine the file, repeat BGSAVE and stable copy, inspect disk errors and never repair the sole original artifact in place.
Security notes
- Backups include every secret stored in Redis. Audit repository reads and securely remove staging files.
Alternatives
- Back up a coordinated AOF multipart set for tighter RPO only with manifest-aware atomic capture and a tested restore procedure.
Stop conditions
- Stop if source save status is not ok, checksum changes, validation fails, repository encryption/ownership is unknown or retention is missing.
command
Restore into an isolated compatible Redis instance
Provision an isolated loopback-only Redis Open Source 8.8 instance, place the verified RDB with correct ownership, disable AOF for initial RDB validation, start on {{restorePort}} and inspect keyspace without any production network path.
Why this step matters
Isolation prevents restored stale data, credentials, queue messages or side effects from reaching production clients. Matching Redis 8.8 avoids persistence-format surprises. Disabling AOF in this disposable instance ensures the selected RDB is the actual source rather than an old appendonly directory.
What to understand
Use separate host/network credentials when the dataset is sensitive or clients could discover localhost through shared tenancy. Never bind the restore service to a production address.
Compare server log loaded version, key counts and expiry behavior. The RDB can legitimately omit keys expired between snapshot and restore; quantify this against expected TTLs.
System changes
- Creates an isolated Redis process and local restored copy; does not modify production Redis.
Syntax explained
--bind 127.0.0.1- Limits the disposable restore listener to local loopback.
--appendonly no- Ensures RDB is loaded without an AOF taking precedence in the restore directory.
Values stay on this page and are never sent or saved.
sudo install -d -o redis -g redis -m 0750 /var/lib/redis-restore && sudo install -o redis -g redis -m 0640 {{backupDirectory}}/{{backupArtifact}} /var/lib/redis-restore/dump.rdb && sudo -u redis redis-server --bind 127.0.0.1 --port {{restorePort}} --dir /var/lib/redis-restore --dbfilename dump.rdb --appendonly no --daemonize yesRestore listener: 127.0.0.1:6389 Loading RDB produced by version 8.8.0 RDB age 420 seconds RDB memory usage when created 3.18 Mb Done loading RDB, keys loaded: 8, keys expired: 0 DB0:keys=8,expires=1,avg_ttl=86358000
Checkpoint: Verify this layer before continuing
Continue whenIsolated Redis loads the exact digest-verified artifact under Redis 8.8, reports expected databases/counts and has no external listener.
Stop whenStop if it binds externally, loads unexpected AOF, reports corruption/version error or contains unexplained key-count differences.
If this step fails
Restore starts but reports zero keys.
Likely causeWrong directory/file name/ownership, expired fixture, AOF/config precedence or wrong database index was used.
sudo ss -lntp | grep ':{{restorePort}}'redis-cli -p {{restorePort}} INFO keyspacels -l /var/lib/redis-restore
ResolutionStop the disposable instance, correct artifact path and config, verify checksum and restart; do not change production.
Security notes
- The restored dataset is production-sensitive even in isolation. Restrict OS users, logs, swap, snapshots and cleanup.
Alternatives
- Restore on a dedicated quarantined host for application tests that cannot be safely executed on a shared server.
Stop conditions
- Stop if it binds externally, loads unexpected AOF, reports corruption/version error or contains unexplained key-count differences.
verification
Validate application semantics and close the recovery drill
Under an isolated test identity, compare every fixture type, value, length, stream ID and TTL range, run an application canary, measure RPO/RTO, then stop and securely dispose of the restore instance.
Why this step matters
Key count alone cannot prove recovery. Type, exact value, ordering, stream state, TTL and application behavior expose stale or semantically incomplete backups. Measured timestamps determine actual RPO/RTO. Secure cleanup is part of the drill because restored data otherwise becomes an uncontrolled copy.
What to understand
Use a purpose-built verifier rather than unrestricted EVAL when scripting is disabled in production; this isolated command represents concise fixture validation only.
Record sanitized pass/fail, artifact ID, version, digest, restore start/end, expected and actual recovery point, operator and unresolved exceptions. Never copy real values into the report.
Stop the process, verify no listener, remove data according to approved secure deletion and revoke temporary repository/test credentials.
System changes
- Reads restored fixture, runs an isolated application canary and deletes the disposable recovery environment after evidence capture.
Syntax explained
TTL- Confirms expiry remains within the expected range after elapsed backup and restore time.
EVAL ... 0- Runs a local read-only fixture aggregation with zero declared key arguments; production application ACL denies scripting.
Values stay on this page and are never sent or saved.
redis-cli -p {{restorePort}} --no-auth-warning EVAL "return {redis.call('GET','orders:restore:string'),redis.call('HLEN','orders:restore:hash'),redis.call('LLEN','orders:restore:list'),redis.call('TTL','orders:restore:ttl')}" 01) "oneliners-redis-restore-v1" 2) (integer) 2 3) (integer) 3 4) (integer) 86342 Application canary: PASS Backup digest: MATCH Measured RPO: 00:00:42 Measured RTO: 00:11:18 Residual restore listener after cleanup: none
Checkpoint: Verify this layer before continuing
Continue whenAll fixture and application checks pass, RPO/RTO meet contract, evidence is sanitized, temporary credentials are revoked and restore data/listener are gone.
Stop whenStop before declaring backup success on any data mismatch, expired required key, application error, RPO/RTO breach or incomplete cleanup.
If this step fails
Values match but TTL is much shorter than expected.
Likely causeSnapshot is older than recorded, wall clocks differ, restore took too long or TTL was set before snapshot.
date -uredis-cli -p {{restorePort}} TTL orders:restore:ttlredis-cli -p {{restorePort}} INFO server
ResolutionQuantify the recovery-point age and restore duration; correct schedule, time synchronization or RTO design and repeat with a new artifact.
Security notes
- Never connect production clients to a drill. Treat fixture scripts and reports as sensitive operational metadata.
Alternatives
- Use an automated disposable VM/container in a quarantined network, provided it preserves Redis version and filesystem semantics.
Stop conditions
- Stop before declaring backup success on any data mismatch, expired required key, application error, RPO/RTO breach or incomplete cleanup.
Finish line
Verification checklist
redis-server --version && sudo ss -lntp | grep ':{{redisPort}}'Approved Redis Open Source 8.8 patch runs unprivileged on private TLS only.redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} --user {{appUser}} --askpass ACL WHOAMIValid CA and named user work; plaintext, invalid CA, unauthenticated, admin and unrelated namespace tests fail.redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} --user backup-reader --askpass INFO persistenceRDB and AOF are enabled and last save/write/rewrite states are ok with sufficient disk and memory headroom.sudo redis-check-rdb {{backupDirectory}}/{{backupArtifact}} && sudo sha256sum {{backupDirectory}}/{{backupArtifact}}Stable artifact validates, digest matches repository metadata and encryption/retention are confirmed.redis-cli -p {{restorePort}} INFO keyspaceExact artifact restores in isolation, fixture and application checks pass inside RPO/RTO, then all temporary data and access are removed.Recovery guidance
Common problems and safe checks
Redis binary reports an unexpected product or older version.
Likely causeAn OS vendor package, old Redis Community Edition, Redis Stack or another fork shadows the intended Redis Open Source 8.8 binary.
redis-server --versioncommand -v redis-serverapt-cache policy redis-server
ResolutionStop deployment, identify package provenance and install the reviewed official Redis Open Source 8.8 artifact without overwriting production data.
redis-server fails with TLS configuration but starts without it.
Likely causeThe binary lacks TLS support, certificate/key is unreadable, PEM is malformed or CA path is wrong.
redis-server --versionopenssl x509 -in {{redisTlsCert}} -noout -subject -issuer -datesnamei -l {{redisTlsKey}}
ResolutionUse the verified TLS-enabled build and correct file chain/permissions; never fall back to plaintext for production.
Client reports certificate hostname mismatch.
Likely causeThe DNS name used by the client is absent from certificate SAN or resolves to the wrong host.
openssl x509 -in {{redisTlsCert}} -noout -ext subjectAltNamegetent hosts {{redisHost}}
ResolutionIssue a certificate with the approved DNS SAN and connect using that name; do not disable hostname verification.
Redis starts but unauthenticated PING succeeds.
Likely causeThe default ACL user remains `on` or a different ACL file was loaded.
sudo -u redis grep -n '^user default' {{redisAclFile}}systemctl cat redis-server
ResolutionVerify the active `aclfile`, set `user default off`, restart through change control and repeat the unauthenticated negative test.
Application receives NOPERM for an expected command.
Likely causeACL command category, subcommand, key pattern or channel pattern does not cover the real operation.
ACL DRYRUN {{appUser}} GET orders:testACL LOG 10
ResolutionIdentify the exact command/key/channel and add only the missing rule after review; do not grant `+@all`.
Application can read another tenant's key.
Likely causeKey pattern is too broad, application constructs unprefixed keys or a command accesses keys not captured as expected.
ACL GETUSER {{appUser}}ACL DRYRUN {{appUser}} GET unrelated:test
ResolutionBlock traffic, narrow the pattern, fix key construction, review logs and test every command shape including scripts and modules.
Pub/Sub subscription fails or reaches unrelated channels.
Likely causeRedis 8 ACL channel pattern is missing or too broad.
ACL GETUSER {{appUser}}ACL DRYRUN {{appUser}} SUBSCRIBE orders-events:test
ResolutionAdd the exact `&pattern` and required Pub/Sub subcommands, then test an unrelated channel denial.
ACL changes disappear after restart.
Likely causeRuntime `ACL SETUSER` was not persisted with `ACL SAVE`, the ACL file is not active or configuration management overwrote it.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} ACL GETUSER {{appUser}}grep '^aclfile' {{redisConfig}}
ResolutionUpdate the protected source of truth, deploy atomically, run ACL LOAD/SAVE only under approved procedure and test restart.
Redis refuses writes with MISCONF.
Likely causeConfigured snapshot persistence failed and `stop-writes-on-bgsave-error` protected against unpersisted writes.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO persistencejournalctl -u redis-server --since '-15 min'
ResolutionPreserve the safety stop, repair disk/path/permission/resource failure and confirm a successful BGSAVE before resuming.
AOF last write status is error.
Likely causeDisk full, I/O error, read-only filesystem or permission failure prevented append or fsync.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO persistencedf -h {{redisDataDir}}dmesg --level=err,warn
ResolutionStop workload growth, restore reliable storage capacity, preserve files and validate AOF before controlled restart.
AOF rewrite repeatedly fails or consumes excessive resources.
Likely causeInsufficient disk/memory, high write amplification, copy-on-write pressure or slow storage prevents rewrite.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO persistenceredis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO memoryiostat -xz 1 5
ResolutionCapacity-plan peak rewrite, reduce bounded write pressure or move to adequate storage; do not delete active AOF segments.
Memory reaches maxmemory and writes fail.
Likely cause`noeviction` protects durable data while dataset or fragmentation exceeded capacity.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO memoryredis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} MEMORY STATS
ResolutionReduce controlled load, expire/archive intended data or scale memory; do not change to eviction without classifying data loss.
Keys disappear under load.
Likely causeAn eviction policy, TTL behavior, application deletion or restore from an older persistence point removed them.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} CONFIG GET maxmemory-policyredis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO stats
ResolutionInspect `evicted_keys`, expirations and audit evidence; restore only after identifying the cause and align eviction with data classification.
BGSAVE fails with Cannot allocate memory.
Likely causeFork and copy-on-write peak exceeds available memory or overcommit policy and workload churn prevent allocation.
free -hsysctl vm.overcommit_memoryredis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO memory
ResolutionReduce bounded write load, add tested capacity and configure host memory according to official guidance before retrying.
The copied RDB checksum changes or redis-check-rdb fails.
Likely causeThe file was copied while being replaced, transfer was incomplete, storage is corrupt or the wrong artifact was selected.
redis-check-rdb {{backupDirectory}}/{{backupArtifact}}sha256sum {{backupDirectory}}/{{backupArtifact}}
ResolutionDiscard the artifact, trigger/observe a completed BGSAVE, copy atomically from a stable file and verify before off-host upload.
Restore starts with an empty dataset.
Likely causeWrong `dir`/`dbfilename`, permissions, AOF precedence, incompatible config or the service started before the artifact was placed.
redis-server --test-memory 64ls -l {{backupDirectory}}/{{backupArtifact}}grep -E '^(dir|dbfilename|appendonly)' <restore-config>
ResolutionStop the isolated instance, correct paths and ownership, decide AOF versus RDB precedence and restart without touching production.
Restore loads fewer keys than expected.
Likely causeBackup RPO is older, TTLs expired while offline, wrong database index was inspected or source snapshot was incomplete.
redis-cli -p {{restorePort}} INFO keyspaceredis-cli -p {{restorePort}} DBSIZE
ResolutionCompare snapshot time, checksums, per-database counts and TTL semantics; restore a newer verified artifact or declare the RPO breach.
Redis refuses an AOF after abrupt shutdown.
Likely causeThe final AOF command is truncated or multipart manifest/segments are incomplete.
redis-check-aof --fix <copy-of-aof-not-original>
ResolutionWork only on a copy, inspect proposed truncation and quantify lost writes before approval; preserve the original for forensic recovery.
Latency spikes during RDB save or AOF rewrite.
Likely causeFork latency, copy-on-write, CPU scheduling or storage saturation affects the event loop.
redis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} LATENCY DOCTORredis-cli --tls --cacert {{redisTlsCa}} -h {{redisHost}} INFO persistence
ResolutionSchedule operations, provision memory/I/O and tune workload after representative testing; do not disable persistence without RPO approval.
Backup repository contains readable Redis data.
Likely causeEncryption, repository policy, object ownership or upload workflow is missing or misconfigured.
stat {{backupDirectory}}/{{backupArtifact}}sha256sum {{backupDirectory}}/{{backupArtifact}}
ResolutionQuarantine exposure, rotate affected application secrets, encrypt and re-upload through the approved repository workflow, and audit access.
Recovery
Rollback
Do not delete or repair the only persistence files. Remove traffic, preserve config/log/persistence evidence, restore the last reviewed config and ACL through an isolated validation, or replace the node from a verified backup. Credential exposure requires rotation, not only configuration rollback.
- Stop new client traffic through the application connection layer or firewall without opening a plaintext/public fallback.
- Preserve sanitized INFO persistence/memory, logs, active config revision, ACL revision, certificate metadata and hashes of every RDB/AOF file.
- If access policy is wrong, stage the previous reviewed ACL/config on an isolated port, repeat positive/negative tests, then deploy atomically.
- If TLS fails, restore the previous valid certificate/key pair from PKI workflow; never enable plaintext or skip verification.
- If persistence is corrupt, copy all originals read-only, run redis-check tools only on duplicates and quantify any proposed truncation.
- Recover onto an isolated compatible Redis 8.8 instance from the latest verified off-host artifact and validate application semantics.
- Rotate exposed ACL secrets and repository credentials, inspect ACL LOG and network evidence, then return traffic only after all release gates pass.
Evidence