Skip to article
Databases Cache and in-memory data

Redis data persistence

Redis data persistence stores Redis data outside volatile memory so an Azure Redis instance can rehydrate after severe node failure. In Azure Managed Redis, persistence can use RDB snapshots or AOF write logs; it improves durability but is not backup or point-in-time recovery.

Source: Microsoft Learn - Configure data persistence - Azure Managed Redis Reviewed 2026-05-21

Exam trap
Treating Redis persistence as backup or PITR and discovering too late that corrupted writes were durably persisted too.
Production check
Run a read-only show command and confirm the persistence setting, SKU, location, and provisioning state.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Redis persistence, RDB persistence, AOF persistence
Difficulty
fundamentals
CLI mappings
5
Last verified
2026-05-21
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Redis data persistence is the safety net for cache data that should survive a serious Redis node failure. Redis normally keeps data in memory because speed is the point. Persistence adds a durable copy using snapshots or append-only write logs, so the service can rebuild the cache after losing both primary and replica data. It does not protect you from bad application writes, accidental deletes, or needing yesterday’s state. Treat it as durability for recovery, not as a replacement for export, backup design, or source-of-truth data.

Why it matters

Redis data persistence matters because teams often blur the line between “cache” and “temporary database.” When Redis holds sessions, queue hints, leaderboards, deduplication state, or expensive computed results, losing all in-memory data can create a real outage even if the system of record is healthy. Persistence reduces the blast radius of rare node-level data loss and shortens the rebuild path. It also forces better conversations about what data belongs in Redis, what must expire, what can be reconstructed, and what must be exported separately. Without that discipline, teams either overtrust Redis or pay for durability they do not operationally understand.

Technical context

In Azure architecture, Redis data persistence sits in the data platform and reliability layer of Azure Managed Redis or Azure Cache for Redis Enterprise/Premium designs. It affects the cache database configuration, managed disk or storage-backed durability path, high availability plan, and recovery expectations. RDB persistence captures periodic snapshots, while AOF persistence records write operations. Operators connect this setting with cache tier, SKU, replicas, zones, private networking, diagnostics, and the application’s fallback to the durable database when Redis is rebuilding or unavailable.

Exam context

Compare with

Point-in-time restore Redis import export

Where it is used

Where you see it

  1. The Azure Managed Redis persistence page shows RDB or AOF settings, availability by tier, and whether the cache is configured for durable recovery after failures.
  2. CLI output from az redisenterprise database show or az redis show reveals persistence configuration, SKU, provisioning state, and resource identifiers used in change records. and reviews
  3. Azure Monitor and incident logs expose failover, rehydration, server load, cache misses, or backend pressure after Redis recovers from a node-level data loss event. and recovery

Common situations

  • Preserve session, token, or queue-state data when losing all in-memory Redis nodes would create a user-visible outage.
  • Choose RDB snapshots for a workload that can tolerate a wider recovery window but wants simpler durability behavior.
  • Use AOF persistence for write-heavy state where losing recent Redis operations would cause costly reconciliation work.
  • Document why Redis persistence is not a substitute for exports, PITR, or the durable database of record.
  • Test cache rehydration and backend surge behavior before declaring a Redis-backed workflow production-ready.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Gaming platform protects tournament state during peak matches Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A multiplayer gaming platform used Redis to track tournament brackets, lobby membership, and short-lived player readiness state. A node failure during a weekend tournament previously forced manual reconstruction from delayed application logs.

Goals
  • Reduce unrecoverable Redis state loss during tournament windows.
  • Keep player lobby recovery under five minutes after severe node failure.
  • Avoid making Redis the permanent source of truth for match results.
  • Create operator evidence for persistence configuration and failover tests.
Approach using Redis data persistence

Engineers enabled Redis data persistence on the Azure Managed Redis database that held tournament coordination state. They used AOF for write-heavy readiness updates and kept the official match result store in Azure Cosmos DB. Azure CLI captured the database persistence configuration, cluster resource ID, SKU, and provisioning state before each tournament. The application added cache-warm logic to rebuild bracket views from Cosmos DB if Redis returned missing keys. Azure Monitor dashboards tracked write latency, cache misses, server load, and backend query volume during rehearsed failover. The runbook clearly separated AOF recovery from backup: bad bracket updates still had to be corrected in the system of record.

Potential outcomes
  • Tournament recovery time dropped from 27 minutes to under 4 minutes during the next failure drill.
  • Manual bracket reconstruction work fell by 80 percent because most recent Redis writes replayed automatically.
  • P95 Redis write latency stayed below 12 milliseconds after capacity was adjusted for AOF overhead.
  • Operations produced audited JSON evidence for every pre-event persistence check.
What to learn

Redis data persistence is most valuable when fast recovery is paired with a durable source of truth and tested cache-warm behavior.

Scenario 02 Factory telemetry team preserves deduplication state Scenario, objectives, solution, measured impact, and takeaway.
Scenario

An industrial manufacturer used Redis to suppress duplicate machine alerts before sending incidents to Azure Event Hubs. Losing Redis state caused repeated maintenance tickets and unnecessary technician dispatches.

Goals
  • Prevent alert storms after Redis node failures.
  • Keep deduplication state durable for at least the current shift.
  • Avoid long-term retention of raw machine telemetry in Redis.
  • Give plant operators simple checks before production-line maintenance windows.
Approach using Redis data persistence

The platform team configured Redis data persistence with RDB snapshots on the managed Redis instance that stored deduplication keys and alert cooldown windows. The durable telemetry history remained in Azure Data Explorer, while Redis held only compact identifiers with TTLs. Engineers chose RDB because the factory could tolerate losing a few minutes of duplicate-suppression state but needed faster rebuild than a completely cold cache. CLI scripts exported the Redis database configuration, persistence settings, resource tags, and region before each maintenance window. Azure Monitor alerts watched cache misses, server load, and Event Hubs ingress so operators could spot a persistence or rehydration problem quickly.

Potential outcomes
  • Duplicate incident volume after maintenance fell by 62 percent across three production lines.
  • Redis rebuild time after a test failure dropped from 18 minutes to 6 minutes.
  • No raw telemetry payloads were persisted, reducing privacy and storage-governance concerns.
  • Operators gained a two-command checklist for persistence state and provisioning health.
What to learn

Persistence can stabilize operational workflows when Redis stores compact, expiring state that is painful to reconstruct during real incidents.

Scenario 03 Learning platform keeps assessment windows stable Scenario, objectives, solution, measured impact, and takeaway.
Scenario

An online education provider used Redis for exam attempt timers, seat reservations, and short-lived anti-duplication tokens. A regional infrastructure incident previously forced students to restart timed assessments.

Goals
  • Protect active assessment state from rare Redis data loss.
  • Maintain strict separation between exam answers and temporary coordination state.
  • Recover service without overloading the primary database.
  • Document recovery limits for compliance and support teams.
Approach using Redis data persistence

Architects enabled Redis data persistence for the Azure Redis database that stored expiring assessment coordination keys. They avoided persisting answer content; answers stayed in Azure SQL Database with transaction logging. Persistence used a snapshot approach because the platform could recalculate some timers but could not tolerate losing every active reservation. The team added a warmup job that rebuilt missing seat reservations from SQL and capped retry traffic from the exam service. CLI checks recorded persistence mode, cache SKU, private endpoint state, and tags before each exam season. Support runbooks explained that persistence improved node-failure recovery but did not provide point-in-time rollback for mistaken writes.

Potential outcomes
  • Active assessment recovery improved from broad manual resets to targeted reconciliation under 10 minutes.
  • Database CPU spikes during Redis recovery dropped by 35 percent because warmup jobs throttled cache rebuilds.
  • Support tickets for lost attempt windows decreased by 48 percent during the following semester.
  • Compliance reviewers received clear evidence that answer data was not stored in Redis persistence files.
What to learn

Redis persistence helps learner-facing systems stay stable when temporary state matters but must not replace the protected system of record.

Azure CLI

Azure CLI is useful for Redis data persistence because durability settings need repeatable proof across environments. I use CLI to capture the cache or database configuration, persistence mode, SKU, region, and provisioning state before a change window. Portal screenshots are easy to misread during incidents; JSON output can be stored in a change ticket, compared with policy baselines, and checked from automation. CLI also helps separate persistence questions from networking or authentication failures. When a team says Redis data is protected, commands give the evidence: which resource, which persistence setting, which subscription, and which timestamp was actually verified. That prevents guesswork during audits.

Useful for

  • Inventory Redis databases and caches to find which production workloads have persistence enabled or missing.
  • Compare persistence settings between staging and production before a Redis migration or tier change.
  • Update a Redis Enterprise database with an approved persistence configuration during a controlled change window.
  • Capture SKU, region, persistence, and provisioning state as incident evidence after a Redis data-loss event.
  • Validate that a new Premium or Enterprise Redis deployment includes the intended RDB or AOF configuration.

Before you run a command

  • Confirm tenant, subscription, resource group, cache or cluster name, database name, region, and whether you are targeting Azure Managed Redis or Azure Cache for Redis.
  • Check that the account has Microsoft.Cache permissions and that update commands are approved because persistence changes can affect cost, recovery behavior, and write latency.
  • Know whether the JSON or shorthand persistence payload represents RDB, AOF, frequency, or disabled persistence before applying it to production.
  • Use read-only show commands first, then capture JSON output with timestamps for the change record and rollback comparison.
  • Coordinate with application owners because cache rehydration, cold-cache misses, and client reconnect behavior may appear during validation.

What the output tells you

  • Persistence fields show whether Redis is using durable snapshots, append-only logging, or no persistence for the selected database or cache.
  • SKU and tier fields tell you whether the chosen persistence mode is supported and whether extra capacity planning is needed.
  • Provisioning state tells you whether a create or update operation is still running, failed, or ready for application validation.
  • Resource ID, location, and tags identify the owner, region, and environment where durability evidence applies.
  • Metric output after the change shows whether server load, latency, cache misses, or backend pressure increased unexpectedly.

Mapped commands

Redis Data Persistence CLI operations

adjacent 
az redisenterprise database show --cluster-name <cluster-name> --resource-group <resource-group>
az redisenterprise databasediscoverDatabases
read-only Microsoft Learn 
az redisenterprise database update --cluster-name <cluster-name> --resource-group <resource-group> --persistence <persistence-json-or-shorthand>
az redisenterprise databaseconfigureDatabases
mutating Microsoft Learn 
az redisenterprise create --cluster-name <cluster-name> --resource-group <resource-group> --location <region> --sku <sku> --persistence <persistence-json-or-shorthand>
az redisenterpriseprovisionDatabases
mutating Microsoft Learn 
az redis show --name <cache-name> --resource-group <resource-group>
az redisdiscoverDatabases
read-only Microsoft Learn 
az redis create --name <cache-name> --resource-group <resource-group> --location <region> --sku Premium --vm-size P1 --redis-configuration @config_rdb.json
az redisprovisionDatabases
mutating Microsoft Learn

Architecture context

A seasoned Azure architect treats Redis persistence as part of the recovery design, not a checkbox. I want to know which data is cached, which data is authoritative, how long it can be stale, and what happens while the cache is rehydrating. The design should line up tier selection, high availability, zone strategy, private endpoints, storage or managed disk implications, monitoring, and application retry behavior. RDB is usually easier to reason about for snapshots; AOF can reduce data-loss windows but adds write-log considerations. Persistence should be tested with failover drills, not merely enabled during provisioning. That evidence should be reviewed after every major workload or tier change.

Security
Security impact is indirect but important because persistence creates a durable copy of data that originally lived only in memory. If Redis stores session tokens, user identifiers, authorization hints, or personal data fragments, the persistence layer must be governed like sensitive storage. Access to configure persistence should be limited to trusted operators because changing it can affect durability, cost, and incident evidence. Use private networking, encrypted client protocols, managed identity or access controls where available, and careful Key Vault handling for connection material. Persistence does not sanitize bad data, so application-level data minimization still matters. Review persisted-cache contents during data-classification and privacy assessments.
Cost
Cost impact can be direct or indirect depending on tier and persistence mode. Persistence may require higher Redis tiers, managed disk or storage usage, additional operational testing, more diagnostics, and careful retention of export artifacts. AOF can increase write-path overhead and storage activity, while RDB may be cheaper but allow a larger data-loss window between snapshots. The real FinOps question is whether persistence avoids backend scale-out, expensive cache rebuilds, or business downtime. Teams should tag the cache owner, document why durability is required, and compare persistence cost with the cost of reconstructing lost cache state. Review these assumptions during quarterly capacity and resilience planning.
Reliability
Reliability impact is direct. Persistence helps an Azure Redis instance recover data after a catastrophic loss of both primary and replica in-memory state. It does not provide point-in-time restore, and it does not undo corrupt writes that were already persisted. Reliable designs define recovery objectives, test rehydration behavior, monitor persistence status, and maintain a cache-miss fallback to the system of record. Zone redundancy, replicas, active geo-replication, and export jobs may still be needed depending on the workload. Operators should rehearse maintenance and failure scenarios before Redis becomes critical to user-facing workflows. Practice this during maintenance windows so timing assumptions are not invented mid-incident.
Performance
Performance impact depends on persistence mode, write volume, cache size, and tier. RDB snapshots can create background work that must be sized into capacity planning. AOF records write operations and can add overhead to write-heavy workloads, though it can reduce recovery data loss compared with coarse snapshots. Rehydration after failure can also affect application response time while hot keys repopulate. Performance testing should measure normal latency, peak writes, failover, cold-cache behavior, and backend load during rebuild. Do not judge persistence only by average Redis latency; inspect tail latency and cache-miss pressure too. Capture these metrics before and after enabling persistence in production.
Operations
Operators manage Redis persistence by checking whether persistence is enabled, which mode is configured, how often snapshots or write logs are captured, and whether the cache tier supports the selected setting. They review Azure Monitor metrics, provisioning state, failover events, storage or managed disk dependencies, and application cache-warm behavior. Before changes, they capture CLI output, configuration JSON, and cost notes. During incidents, they distinguish between rehydration, client reconnect problems, and backend overload from cache misses. Runbooks should include export decisions, test restores where applicable, and evidence that persistence is not being mistaken for PITR. They also verify alert owners before production workloads depend on the setting.

Common mistakes

  • Treating Redis persistence as backup or PITR and discovering too late that corrupted writes were durably persisted too.
  • Enabling AOF or RDB without testing latency, cold-cache behavior, and backend load during rehydration.
  • Applying persistence settings to the wrong subscription, resource group, cluster, or database because names are similar.
  • Ignoring sensitive data retained by persistence files when Redis contains session identifiers or personal data fragments.
  • Assuming every Redis tier supports the same persistence behavior instead of checking the selected Azure service and SKU.