{
  "id": "database-persistence",
  "title": "Configure database persistence",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/databases/configure/database-persistence/",
  "summary": "How to configure database persistence with either an append-only file (AOF) or snapshots.",
  "content": "\nData is stored in RAM or a combination of RAM and flash memory ([Auto Tiering]()), which risks data loss during process or server failures. Redis Enterprise Software supports multiple methods to persist data to disk on a per-database basis to ensure data durability.\n\nYou can configure [persistence](https://redis.com/redis-enterprise/technology/durable-redis/) during database creation or by editing an existing database. Although the persistence model can be changed dynamically, the switch can take time depending on the database size and the models being switched.\n\n## Configure database persistence\n\nYou can configure persistence when you [create a database](), or you can edit an existing database's configuration:\n\n1. From the **Databases** list, select the database, then select **Configuration**.\n\n1. Select **Edit**.\n\n1. Expand the **Durability** section.\n\n1. For **Persistence**, select an [option](#data-persistence-options) from the list.\n\n1. Select **Save**.\n\n## Data persistence options\n\nThere are six options for persistence in Redis Enterprise Software:\n\n|  **Options** | **Description** |\n|  ------ | ------ |\n|  None | Data is not persisted to disk at all. |\n|  Append-only file (AOF) - fsync every write | Data is fsynced to disk with every write. |\n|  Append-only file (AOF) - fsync every 1 sec | Data is fsynced to disk every second. |\n|  Snapshot, every 1 hour | A snapshot of the database is created every hour. |\n|  Snapshot, every 6 hours | A snapshot of the database is created every 6 hours. |\n|  Snapshot, every 12 hours | A snapshot of the database is created every 12 hours. |\n\n## Select a persistence strategy\n\nWhen selecting your persistence strategy, you should take into account your tolerance for data loss and performance needs. There will always be tradeoffs between the two.\nThe fsync() system call syncs data from file buffers to disk. You can configure how often Redis performs an fsync() to most effectively make tradeoffs between performance and durability for your use case.\nRedis supports three fsync policies: every write, every second, and disabled.\n\nRedis also allows snapshots through RDB files for persistence. Within Redis Enterprise, you can configure both snapshots and fsync policies.\n\nFor any high availability needs, use replication to further reduce the risk of data loss.\n\n**For use cases where data loss has a high cost:**\n\nAppend-only file (AOF) - fsync every write - Redis Enterprise sets the Redis directive `appendfsyncalways`.  With this policy, Redis will wait for the write and the fsync to complete prior to sending an acknowledgement to the client that the data has written. This introduces the performance overhead of the fsync in addition to the execution of the command. The fsync policy always favors durability over performance and should be used when there is a high cost for data loss.\n\n**For use cases where data loss is tolerable only limitedly:**\n\nAppend-only file (AOF) - fsync every 1 sec - Redis will fsync any newly written data every second. This policy balances performance and durability and should be used when minimal data loss is acceptable in the event of a failure. This is the default Redis policy. This policy could result in between 1 and 2 seconds worth of data loss but on average this will be closer to one second.\n\n\nIf you use AOF for persistence, enable replication to improve performance. When both features are enabled for a database, the replica handles persistence, which prevents any performance impact on the master.\n\n\n**For use cases where data loss is tolerable or recoverable for extended periods of time:**\n\n- Snapshot, every 1 hour - Performs a full backup every hour.\n- Snapshot, every 6 hour - Performs a full backup every 6 hours.\n- Snapshot, every 12 hour - Performs a full backup every 12 hours.\n- None - Does not back up or persist data at all.\n\n## Append-only file (AOF) vs snapshot (RDB)\n\nNow that you know the available options, to assist in making a decision\non which option is right for your use case, here is a table about the\ntwo:\n\n|  **Append-only File (AOF)** | **Snapshot (RDB)** |\n|------------|-----------------|\n|  More resource intensive | Less resource intensive |\n|  Provides better durability (recover the latest point in time) | Less durable |\n|  Slower time to recover (Larger files) | Faster recovery time |\n|  More disk space required (files tend to grow large and require compaction) | Requires less resources (I/O once every several hours and no compaction required) |\n\n## Active-Active data persistence \n\nActive-Active databases support AOF persistence only.  Snapshot persistence is not supported for Active-Active databases.\n\nIf an Active-Active database is using snapshot persistence, use `crdb-cli` to switch to AOF persistence:\n\n```text\ncrdb-cli crdb update --crdb-guid \u003cCRDB_GUID\u003e --default-db-config \\\n   '{\"data_persistence\": \"aof\", \"aof_policy\":\"appendfsync-every-sec\"}'\n```\n\n## Auto Tiering data persistence\n\nAuto Tiering flash storage is not considered persistent storage.\n\nFlash-based databases are expected to hold larger datasets, and shard repair times can take longer after node failures. To better protect the database against node failures with longer repair times, consider enabling master and replica dual data persistence.\n\nHowever, dual data persistence with replication adds some processor\nand network overhead, especially for cloud configurations\nwith network-attached persistent storage, such as EBS-backed\nvolumes in AWS.\n\nThere may be times when performance is critical for your use case and\nyou don't want to risk data persistence adding latency.\n\nYou can enable or turn off data persistence on the master shards using the\nfollowing `rladmin` command:\n\n```sh\nrladmin tune db \u003cdatabase_ID_or_name\u003e master_persistence \u003cdisabled | enabled\u003e\n```\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-04-01T08:10:08-05:00"
}