Redis Persistence

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 DanubeData managed Redis instances.

Overview

Redis offers multiple persistence mechanisms:

RDB (Redis Database): Point-in-time snapshots
AOF (Append-Only File): Log of all write operations
Hybrid: Combination of RDB and AOF (recommended)
No Persistence: Pure cache mode

Persistence Methods

RDB - Snapshot Persistence

RDB creates point-in-time snapshots of your dataset at specified intervals.

How RDB Works

Fork process to create child
Child writes dataset to temporary RDB file
Atomic rename replaces old RDB with new one
Snapshot complete

RDB Advantages

Compact: Single file, easy to backup
Fast Restart: Quick loading on startup
Performance: Minimal impact on performance
Good for Backups: Perfect for disaster recovery

RDB Disadvantages

Data Loss Risk: May lose data since last snapshot
Fork Overhead: Memory spike during fork
Not Real-time: Periodic snapshots only

RDB Configuration

# Save snapshot if:
save 900 1      # At least 1 key changed in 900 seconds (15 min)
save 300 10     # At least 10 keys changed in 300 seconds (5 min)
save 60 10000   # At least 10000 keys changed in 60 seconds

Default Schedule: Snapshots every 15 minutes if data changed

AOF - Append-Only File

AOF logs every write operation received by the server.

How AOF Works

Client sends write command
Redis executes command
Command appended to AOF buffer
Buffer flushed to disk (based on policy)
Periodic AOF rewrite for compaction

AOF Advantages

Durable: Minimal data loss (1 second max)
Append-Only: Corruption-resistant
Readable: Human-readable format
Auto-Rewrite: Automatic compaction

AOF Disadvantages

Larger Files: Bigger than equivalent RDB
Slower: More disk I/O operations
Slower Restart: Takes longer to reload

AOF Sync Policies

Three fsync policies available:

always (Maximum Durability)

appendfsync always

Fsync after every write
Slowest but safest
~500-1000 ops/sec
Zero data loss (except disk failure)

everysec (Balanced - Recommended)

appendfsync everysec

Fsync once per second
Good performance
~10k-50k ops/sec
May lose 1 second of data

no (Fastest, Least Safe)

appendfsync no

OS decides when to fsync
Fastest performance
May lose up to 45 seconds of data
Not recommended for production

Hybrid Persistence (Recommended)

Use both RDB and AOF for maximum benefit:

RDB: Fast restarts and compact backups
AOF: Durability and minimal data loss
Startup: Loads from AOF (more complete)
Backups: Uses RDB (more compact)

Configuring Persistence

Via Dashboard

Navigate to your Redis instance
Click Settings > Persistence
Select persistence mode:
- None: Pure cache, no persistence
- RDB Only: Snapshots only
- AOF Only: Append-only log
- RDB + AOF: Hybrid (recommended)
Configure options:
- RDB Snapshot Frequency: 5, 15, or 60 minutes
- AOF Sync Policy: always, everysec, or no
Click Save Changes

Note: Changing persistence requires instance restart

Recommended Configurations

Production (Hybrid)

# Enable both
RDB: Enabled
AOF: Enabled

# RDB settings
Snapshot Frequency: 15 minutes

# AOF settings
Sync Policy: everysec
Auto-Rewrite: Enabled

Best for: Production workloads requiring balance of durability and performance

Cache-Only (No Persistence)

RDB: Disabled
AOF: Disabled

Best for: True cache workloads where data can be regenerated

Maximum Durability (AOF Always)

RDB: Enabled (for backups)
AOF: Enabled
Sync Policy: always

Best for: Critical data requiring maximum durability

Data Recovery

Automatic Recovery

On restart, Redis automatically loads data:

Check for AOF file
If AOF exists, load from AOF (most complete)
If no AOF, load from RDB
If neither, start with empty dataset

Recovery Time

Data Size	RDB Load Time	AOF Load Time
1 GB	~10 seconds	~45 seconds
10 GB	~90 seconds	~5 minutes
50 GB	~7 minutes	~25 minutes
100 GB	~15 minutes	~50 minutes

Manual Recovery

If data corruption occurs:

From Backup:

# Stop Redis
# Replace dump.rdb with backup
cp /backup/dump.rdb /data/dump.rdb
# Start Redis

From AOF:

# Check AOF integrity
redis-check-aof appendonly.aof

# Fix corrupted AOF
redis-check-aof --fix appendonly.aof

# Restart Redis

Via Dashboard:
- Navigate to Backups tab
- Select backup to restore
- Click Restore
- Confirm restoration

Monitoring Persistence

Key Metrics

Monitor these persistence metrics:

Last Save Time: When last RDB snapshot taken
Last Rewrite Time: When AOF last rewritten
RDB Changes Since Save: Keys modified since snapshot
AOF Size: Current AOF file size
AOF Rewrite in Progress: Status of rewrite

Redis Commands

# Check last save
LASTSAVE

# Get persistence info
INFO persistence

# Output:
# loading:0
# rdb_changes_since_last_save:100
# rdb_bgsave_in_progress:0
# rdb_last_save_time:1634567890
# rdb_last_bgsave_status:ok
# rdb_last_bgsave_time_sec:1
# aof_enabled:1
# aof_rewrite_in_progress:0
# aof_last_rewrite_time_sec:2
# aof_current_size:1024000
# aof_base_size:512000

# Force RDB snapshot
BGSAVE

# Force AOF rewrite
BGREWRITEAOF

Performance Impact

RDB Performance Impact

During Snapshot:

Brief CPU spike (fork process)
Memory spike (copy-on-write)
Minimal latency impact
One-time cost per snapshot

Typical Impact:

Latency: +1-5ms during fork
Memory: +10-20% temporarily
CPU: +5-10% during write

AOF Performance Impact

Continuous:

Steady I/O overhead
Log every write operation
Depends on sync policy

everysec (Recommended):

Latency: +0.5-1ms average
CPU: +3-5%
Disk I/O: Moderate

always (Maximum Durability):

Latency: +5-20ms average
CPU: +10-15%
Disk I/O: High

AOF Rewrite Impact

During Rewrite:

Background process
Minimal impact on operations
Temporary disk space usage

Typical Impact:

Latency: +2-5ms
CPU: +10-15%
Duration: 30-120 seconds

Best Practices

Choosing Persistence Mode

Use No Persistence when:

Data can be easily regenerated
Using Redis purely as cache
Maximum performance required
Can tolerate complete data loss

Use RDB Only when:

Periodic snapshots acceptable
Fast restart important
Minimizing disk I/O
Can tolerate some data loss

Use AOF Only when:

Maximum durability required
Slower restart acceptable
Write performance not critical

Use Hybrid when:

Production environment
Balance of all factors
Best overall solution

Backup Strategy

Enable Persistence: Always use persistence for production
Regular Backups: Daily backups to external storage
Test Restores: Regularly test backup restoration
Multiple Copies: Keep backups in multiple locations
Retention Policy: Retain backups for 7-30 days

Performance Optimization

Use everysec: Best balance of durability/performance
Monitor File Sizes: Watch AOF growth
Enable Auto-Rewrite: Keep AOF size manageable
Schedule Snapshots: During low-traffic periods
Sufficient Disk Space: 2-3x data size for safety

Monitoring

Watch Last Save Time: Ensure snapshots completing
Monitor File Sizes: Catch runaway growth
Check Rewrite Status: Ensure rewrites succeeding
Alert on Failures: Immediate notification on issues
Disk Space Alerts: Warning before running out

Troubleshooting

RDB Snapshot Failures

Symptoms: "Last save status: failed" in INFO

Common Causes:

Insufficient disk space
Permission issues
Memory limits (fork failure)
I/O errors

Solutions:

# Check disk space
df -h

# Check Redis logs
tail -f /var/log/redis/redis-server.log

# Try manual snapshot
BGSAVE

# Check result
LASTSAVE
INFO persistence

AOF Write Failures

Symptoms: AOF write errors in logs

Causes:

Disk full
I/O errors
Filesystem issues

Solutions:

# Check disk
df -h
df -i  # Check inodes

# Check filesystem
fsck -n /dev/sda1

# Force AOF rewrite
BGREWRITEAOF

AOF Corruption

Symptoms: Redis won't start, AOF load errors

Solution:

# Check AOF integrity
redis-check-aof /path/to/appendonly.aof

# If corrupted, try to fix
redis-check-aof --fix /path/to/appendonly.aof

# Backup before fixing!
cp appendonly.aof appendonly.aof.backup

# Restart Redis after fix

Slow Restart

Symptoms: Redis taking too long to start

Causes:

Large dataset
Using AOF (slower than RDB)
Disk I/O limitations

Solutions:

Be patient with large datasets
Consider using RDB for faster restarts
Use faster storage (already on NVMe with DanubeData)
Reduce data size if possible

Advanced Topics

AOF Rewrite Configuration

Configure automatic AOF rewrite:

# Rewrite when AOF size 100% bigger than base
auto-aof-rewrite-percentage 100

# Don't rewrite if AOF smaller than 64MB
auto-aof-rewrite-min-size 64mb

Disk Space Management

Monitor and manage disk usage:

# Check current space
INFO persistence

# AOF size and base size
aof_current_size:1024000
aof_base_size:512000

# Calculate growth
growth = (current_size / base_size - 1) * 100
# If growth > 100%, rewrite recommended

Copy-on-Write Behavior

Understanding RDB memory impact:

# Before snapshot: 10 GB used
# During snapshot: 10-12 GB used (COW overhead)
# After snapshot: 10 GB used

Tip: Ensure 20-30% free memory for COW overhead

Redis Persistence

Overview

Persistence Methods

RDB - Snapshot Persistence

How RDB Works

RDB Advantages

RDB Disadvantages

RDB Configuration

AOF - Append-Only File

How AOF Works

AOF Advantages

AOF Disadvantages

AOF Sync Policies

Hybrid Persistence (Recommended)

Configuring Persistence

Via Dashboard

Recommended Configurations

Production (Hybrid)

Cache-Only (No Persistence)

Maximum Durability (AOF Always)

Data Recovery

Automatic Recovery

Recovery Time

Manual Recovery

Monitoring Persistence

Key Metrics

Redis Commands

Performance Impact

RDB Performance Impact

AOF Performance Impact

AOF Rewrite Impact

Best Practices

Choosing Persistence Mode

Backup Strategy

Performance Optimization

Monitoring

Troubleshooting

RDB Snapshot Failures

AOF Write Failures

AOF Corruption

Slow Restart

Advanced Topics

AOF Rewrite Configuration

Disk Space Management

Copy-on-Write Behavior

Related Documentation