{"slug":"cache-persistence","title":"Redis Persistence","description":"Redis persistence allows you to save your in-memory data to disk, protecting against data loss from restarts or failures. This guide covers persistence options, configuration, and best practices for D...","section":"Features","url":"https://docs.danubedata.ro/cache-persistence","markdown_url":"https://docs.danubedata.ro/cache-persistence.md","breadcrumbs":[{"title":"Features","slug":null},{"title":"Cache","slug":"cache-overview"},{"title":"Persistence","slug":"cache-persistence"}],"headings":[{"level":1,"title":"Redis Persistence","id":"redis-persistence"},{"level":2,"title":"Overview","id":"overview"},{"level":2,"title":"Persistence Methods","id":"persistence-methods"},{"level":3,"title":"RDB - Snapshot Persistence","id":"rdb-snapshot-persistence"},{"level":4,"title":"How RDB Works","id":"how-rdb-works"},{"level":4,"title":"RDB Advantages","id":"rdb-advantages"},{"level":4,"title":"RDB Disadvantages","id":"rdb-disadvantages"},{"level":4,"title":"RDB Configuration","id":"rdb-configuration"},{"level":3,"title":"AOF - Append-Only File","id":"aof-append-only-file"},{"level":4,"title":"How AOF Works","id":"how-aof-works"},{"level":4,"title":"AOF Advantages","id":"aof-advantages"},{"level":4,"title":"AOF Disadvantages","id":"aof-disadvantages"},{"level":4,"title":"AOF Sync Policies","id":"aof-sync-policies"},{"level":3,"title":"Hybrid Persistence (Recommended)","id":"hybrid-persistence-recommended"},{"level":2,"title":"Configuring Persistence","id":"configuring-persistence"},{"level":3,"title":"Via Dashboard","id":"via-dashboard"},{"level":3,"title":"Recommended Configurations","id":"recommended-configurations"},{"level":4,"title":"Production (Hybrid)","id":"production-hybrid"},{"level":4,"title":"Cache-Only (No Persistence)","id":"cache-only-no-persistence"},{"level":4,"title":"Maximum Durability (AOF Always)","id":"maximum-durability-aof-always"},{"level":2,"title":"Data Recovery","id":"data-recovery"},{"level":3,"title":"Automatic Recovery","id":"automatic-recovery"},{"level":3,"title":"Recovery Time","id":"recovery-time"},{"level":3,"title":"Manual Recovery","id":"manual-recovery"},{"level":2,"title":"Monitoring Persistence","id":"monitoring-persistence"},{"level":3,"title":"Key Metrics","id":"key-metrics"},{"level":3,"title":"Redis Commands","id":"redis-commands"},{"level":2,"title":"Performance Impact","id":"performance-impact"},{"level":3,"title":"RDB Performance Impact","id":"rdb-performance-impact"},{"level":3,"title":"AOF Performance Impact","id":"aof-performance-impact"},{"level":3,"title":"AOF Rewrite Impact","id":"aof-rewrite-impact"},{"level":2,"title":"Best Practices","id":"best-practices"},{"level":3,"title":"Choosing Persistence Mode","id":"choosing-persistence-mode"},{"level":3,"title":"Backup Strategy","id":"backup-strategy"},{"level":3,"title":"Performance Optimization","id":"performance-optimization"},{"level":3,"title":"Monitoring","id":"monitoring"},{"level":2,"title":"Troubleshooting","id":"troubleshooting"},{"level":3,"title":"RDB Snapshot Failures","id":"rdb-snapshot-failures"},{"level":3,"title":"AOF Write Failures","id":"aof-write-failures"},{"level":3,"title":"AOF Corruption","id":"aof-corruption"},{"level":3,"title":"Slow Restart","id":"slow-restart"},{"level":2,"title":"Advanced Topics","id":"advanced-topics"},{"level":3,"title":"AOF Rewrite Configuration","id":"aof-rewrite-configuration"},{"level":3,"title":"Disk Space Management","id":"disk-space-management"},{"level":3,"title":"Copy-on-Write Behavior","id":"copy-on-write-behavior"},{"level":2,"title":"Related Documentation","id":"related-documentation"}],"format":"markdown","word_count":1441,"content":"# Redis Persistence\n\nRedis persistence allows you to save your in-memory data to disk, protecting against data loss from restarts or failures. This guide covers persistence options, configuration, and best practices for DanubeData managed Redis instances.\n\n## Overview\n\nRedis offers multiple persistence mechanisms:\n\n- **RDB (Redis Database)**: Point-in-time snapshots\n- **AOF (Append-Only File)**: Log of all write operations\n- **Hybrid**: Combination of RDB and AOF (recommended)\n- **No Persistence**: Pure cache mode\n\n> **Applies to Redis and Valkey.** Valkey shares Redis's RDB and AOF mechanisms, so everything on this page applies to both. **Dragonfly** instead manages durability through periodic snapshots, configurable from the instance settings.\n\n## Persistence Methods\n\n### RDB - Snapshot Persistence\n\nRDB creates point-in-time snapshots of your dataset at specified intervals.\n\n#### How RDB Works\n\n1. Fork process to create child\n2. Child writes dataset to temporary RDB file\n3. Atomic rename replaces old RDB with new one\n4. Snapshot complete\n\n#### RDB Advantages\n\n- **Compact**: Single file, easy to backup\n- **Fast Restart**: Quick loading on startup\n- **Performance**: Minimal impact on performance\n- **Good for Backups**: Perfect for disaster recovery\n\n#### RDB Disadvantages\n\n- **Data Loss Risk**: May lose data since last snapshot\n- **Fork Overhead**: Memory spike during fork\n- **Not Real-time**: Periodic snapshots only\n\n#### RDB Configuration\n\n```\n# Save snapshot if:\nsave 900 1      # At least 1 key changed in 900 seconds (15 min)\nsave 300 10     # At least 10 keys changed in 300 seconds (5 min)\nsave 60 10000   # At least 10000 keys changed in 60 seconds\n```\n\n**Default Schedule**: Snapshots every 15 minutes if data changed\n\n### AOF - Append-Only File\n\nAOF logs every write operation received by the server.\n\n#### How AOF Works\n\n1. Client sends write command\n2. Redis executes command\n3. Command appended to AOF buffer\n4. Buffer flushed to disk (based on policy)\n5. Periodic AOF rewrite for compaction\n\n#### AOF Advantages\n\n- **Durable**: Minimal data loss (1 second max)\n- **Append-Only**: Corruption-resistant\n- **Readable**: Human-readable format\n- **Auto-Rewrite**: Automatic compaction\n\n#### AOF Disadvantages\n\n- **Larger Files**: Bigger than equivalent RDB\n- **Slower**: More disk I/O operations\n- **Slower Restart**: Takes longer to reload\n\n#### AOF Sync Policies\n\nThree fsync policies available:\n\n**always** (Maximum Durability)\n```\nappendfsync always\n```\n- Fsync after every write\n- Slowest but safest\n- ~500-1000 ops/sec\n- Zero data loss (except disk failure)\n\n**everysec** (Balanced - Recommended)\n```\nappendfsync everysec\n```\n- Fsync once per second\n- Good performance\n- ~10k-50k ops/sec\n- May lose 1 second of data\n\n**no** (Fastest, Least Safe)\n```\nappendfsync no\n```\n- OS decides when to fsync\n- Fastest performance\n- May lose up to 45 seconds of data\n- Not recommended for production\n\n### Hybrid Persistence (Recommended)\n\nUse both RDB and AOF for maximum benefit:\n\n- **RDB**: Fast restarts and compact backups\n- **AOF**: Durability and minimal data loss\n- **Startup**: Loads from AOF (more complete)\n- **Backups**: Uses RDB (more compact)\n\n## Configuring Persistence\n\n### Via Dashboard\n\n1. Navigate to your Redis instance\n2. Click **Settings** > **Persistence**\n3. Select persistence mode:\n   - **None**: Pure cache, no persistence\n   - **RDB Only**: Snapshots only\n   - **AOF Only**: Append-only log\n   - **RDB + AOF**: Hybrid (recommended)\n4. Configure options:\n   - **RDB Snapshot Frequency**: 5, 15, or 60 minutes\n   - **AOF Sync Policy**: always, everysec, or no\n5. Click **Save Changes**\n\n> **Note**: Changing persistence requires instance restart\n\n### Recommended Configurations\n\n#### Production (Hybrid)\n\n```\n# Enable both\nRDB: Enabled\nAOF: Enabled\n\n# RDB settings\nSnapshot Frequency: 15 minutes\n\n# AOF settings\nSync Policy: everysec\nAuto-Rewrite: Enabled\n```\n\n**Best for**: Production workloads requiring balance of durability and performance\n\n#### Cache-Only (No Persistence)\n\n```\nRDB: Disabled\nAOF: Disabled\n```\n\n**Best for**: True cache workloads where data can be regenerated\n\n#### Maximum Durability (AOF Always)\n\n```\nRDB: Enabled (for backups)\nAOF: Enabled\nSync Policy: always\n```\n\n**Best for**: Critical data requiring maximum durability\n\n## Data Recovery\n\n### Automatic Recovery\n\nOn restart, Redis automatically loads data:\n\n1. Check for AOF file\n2. If AOF exists, load from AOF (most complete)\n3. If no AOF, load from RDB\n4. If neither, start with empty dataset\n\n### Recovery Time\n\n| Data Size | RDB Load Time | AOF Load Time |\n|-----------|---------------|---------------|\n| 1 GB | ~10 seconds | ~45 seconds |\n| 10 GB | ~90 seconds | ~5 minutes |\n| 50 GB | ~7 minutes | ~25 minutes |\n| 100 GB | ~15 minutes | ~50 minutes |\n\n### Manual Recovery\n\nIf data corruption occurs:\n\n1. **From Backup**:\n   ```bash\n   # Stop Redis\n   # Replace dump.rdb with backup\n   cp /backup/dump.rdb /data/dump.rdb\n   # Start Redis\n   ```\n\n2. **From AOF**:\n   ```bash\n   # Check AOF integrity\n   redis-check-aof appendonly.aof\n   \n   # Fix corrupted AOF\n   redis-check-aof --fix appendonly.aof\n   \n   # Restart Redis\n   ```\n\n3. **Via Dashboard**:\n   - Navigate to **Backups** tab\n   - Select backup to restore\n   - Click **Restore**\n   - Confirm restoration\n\n## Monitoring Persistence\n\n### Key Metrics\n\nMonitor these persistence metrics:\n\n- **Last Save Time**: When last RDB snapshot taken\n- **Last Rewrite Time**: When AOF last rewritten\n- **RDB Changes Since Save**: Keys modified since snapshot\n- **AOF Size**: Current AOF file size\n- **AOF Rewrite in Progress**: Status of rewrite\n\n### Redis Commands\n\n```bash\n# Check last save\nLASTSAVE\n\n# Get persistence info\nINFO persistence\n\n# Output:\n# loading:0\n# rdb_changes_since_last_save:100\n# rdb_bgsave_in_progress:0\n# rdb_last_save_time:1634567890\n# rdb_last_bgsave_status:ok\n# rdb_last_bgsave_time_sec:1\n# aof_enabled:1\n# aof_rewrite_in_progress:0\n# aof_last_rewrite_time_sec:2\n# aof_current_size:1024000\n# aof_base_size:512000\n\n# Force RDB snapshot\nBGSAVE\n\n# Force AOF rewrite\nBGREWRITEAOF\n```\n\n## Performance Impact\n\n### RDB Performance Impact\n\n**During Snapshot**:\n- Brief CPU spike (fork process)\n- Memory spike (copy-on-write)\n- Minimal latency impact\n- One-time cost per snapshot\n\n**Typical Impact**:\n- Latency: +1-5ms during fork\n- Memory: +10-20% temporarily\n- CPU: +5-10% during write\n\n### AOF Performance Impact\n\n**Continuous**:\n- Steady I/O overhead\n- Log every write operation\n- Depends on sync policy\n\n**everysec** (Recommended):\n- Latency: +0.5-1ms average\n- CPU: +3-5%\n- Disk I/O: Moderate\n\n**always** (Maximum Durability):\n- Latency: +5-20ms average\n- CPU: +10-15%\n- Disk I/O: High\n\n### AOF Rewrite Impact\n\n**During Rewrite**:\n- Background process\n- Minimal impact on operations\n- Temporary disk space usage\n\n**Typical Impact**:\n- Latency: +2-5ms\n- CPU: +10-15%\n- Duration: 30-120 seconds\n\n## Best Practices\n\n### Choosing Persistence Mode\n\n**Use No Persistence** when:\n- Data can be easily regenerated\n- Using Redis purely as cache\n- Maximum performance required\n- Can tolerate complete data loss\n\n**Use RDB Only** when:\n- Periodic snapshots acceptable\n- Fast restart important\n- Minimizing disk I/O\n- Can tolerate some data loss\n\n**Use AOF Only** when:\n- Maximum durability required\n- Slower restart acceptable\n- Write performance not critical\n\n**Use Hybrid** when:\n- Production environment\n- Balance of all factors\n- Best overall solution\n\n### Backup Strategy\n\n1. **Enable Persistence**: Always use persistence for production\n2. **Regular Backups**: Daily backups to external storage\n3. **Test Restores**: Regularly test backup restoration\n4. **Multiple Copies**: Keep backups in multiple locations\n5. **Retention Policy**: Retain backups for 7-30 days\n\n### Performance Optimization\n\n1. **Use everysec**: Best balance of durability/performance\n2. **Monitor File Sizes**: Watch AOF growth\n3. **Enable Auto-Rewrite**: Keep AOF size manageable\n4. **Schedule Snapshots**: During low-traffic periods\n5. **Sufficient Disk Space**: 2-3x data size for safety\n\n### Monitoring\n\n1. **Watch Last Save Time**: Ensure snapshots completing\n2. **Monitor File Sizes**: Catch runaway growth\n3. **Check Rewrite Status**: Ensure rewrites succeeding\n4. **Alert on Failures**: Immediate notification on issues\n5. **Disk Space Alerts**: Warning before running out\n\n## Troubleshooting\n\n### RDB Snapshot Failures\n\n**Symptoms**: \"Last save status: failed\" in INFO\n\n**Common Causes**:\n- Insufficient disk space\n- Permission issues\n- Memory limits (fork failure)\n- I/O errors\n\n**Solutions**:\n```bash\n# Check disk space\ndf -h\n\n# Check Redis logs\ntail -f /var/log/redis/redis-server.log\n\n# Try manual snapshot\nBGSAVE\n\n# Check result\nLASTSAVE\nINFO persistence\n```\n\n### AOF Write Failures\n\n**Symptoms**: AOF write errors in logs\n\n**Causes**:\n- Disk full\n- I/O errors\n- Filesystem issues\n\n**Solutions**:\n```bash\n# Check disk\ndf -h\ndf -i  # Check inodes\n\n# Check filesystem\nfsck -n /dev/sda1\n\n# Force AOF rewrite\nBGREWRITEAOF\n```\n\n### AOF Corruption\n\n**Symptoms**: Redis won't start, AOF load errors\n\n**Solution**:\n```bash\n# Check AOF integrity\nredis-check-aof /path/to/appendonly.aof\n\n# If corrupted, try to fix\nredis-check-aof --fix /path/to/appendonly.aof\n\n# Backup before fixing!\ncp appendonly.aof appendonly.aof.backup\n\n# Restart Redis after fix\n```\n\n### Slow Restart\n\n**Symptoms**: Redis taking too long to start\n\n**Causes**:\n- Large dataset\n- Using AOF (slower than RDB)\n- Disk I/O limitations\n\n**Solutions**:\n- Be patient with large datasets\n- Consider using RDB for faster restarts\n- Use faster storage (already on NVMe with DanubeData)\n- Reduce data size if possible\n\n## Advanced Topics\n\n### AOF Rewrite Configuration\n\nConfigure automatic AOF rewrite:\n\n```\n# Rewrite when AOF size 100% bigger than base\nauto-aof-rewrite-percentage 100\n\n# Don't rewrite if AOF smaller than 64MB\nauto-aof-rewrite-min-size 64mb\n```\n\n### Disk Space Management\n\nMonitor and manage disk usage:\n\n```bash\n# Check current space\nINFO persistence\n\n# AOF size and base size\naof_current_size:1024000\naof_base_size:512000\n\n# Calculate growth\ngrowth = (current_size / base_size - 1) * 100\n# If growth > 100%, rewrite recommended\n```\n\n### Copy-on-Write Behavior\n\nUnderstanding RDB memory impact:\n\n```\n# Before snapshot: 10 GB used\n# During snapshot: 10-12 GB used (COW overhead)\n# After snapshot: 10 GB used\n```\n\n**Tip**: Ensure 20-30% free memory for COW overhead\n\n## Related Documentation\n\n- [Redis Overview](https://docs.danubedata.ro/cache-redis)\n- [Redis Replicas](https://docs.danubedata.ro/cache-replicas)\n- [Cache Monitoring](https://docs.danubedata.ro/cache-monitoring)\n- [Database Backups](https://docs.danubedata.ro/databases-backups)\n- [Platform SLA](https://docs.danubedata.ro/platform-sla)\n\n","prev":{"title":"Redis Replicas","slug":"cache-replicas","url":"https://docs.danubedata.ro/cache-replicas","markdown_url":"https://docs.danubedata.ro/cache-replicas.md","json_url":"https://docs.danubedata.ro/cache-replicas.json"},"next":{"title":"Monitoring","slug":"cache-monitoring","url":"https://docs.danubedata.ro/cache-monitoring","markdown_url":"https://docs.danubedata.ro/cache-monitoring.md","json_url":"https://docs.danubedata.ro/cache-monitoring.json"},"index_url":"https://docs.danubedata.ro/index.json"}