# 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

> **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.

## Persistence Methods

### RDB - Snapshot Persistence

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

#### How RDB Works

1. Fork process to create child
2. Child writes dataset to temporary RDB file
3. Atomic rename replaces old RDB with new one
4. 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

1. Client sends write command
2. Redis executes command
3. Command appended to AOF buffer
4. Buffer flushed to disk (based on policy)
5. 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

1. Navigate to your Redis instance
2. Click **Settings** > **Persistence**
3. Select persistence mode:
   - **None**: Pure cache, no persistence
   - **RDB Only**: Snapshots only
   - **AOF Only**: Append-only log
   - **RDB + AOF**: Hybrid (recommended)
4. Configure options:
   - **RDB Snapshot Frequency**: 5, 15, or 60 minutes
   - **AOF Sync Policy**: always, everysec, or no
5. 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:

1. Check for AOF file
2. If AOF exists, load from AOF (most complete)
3. If no AOF, load from RDB
4. 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:

1. **From Backup**:
   ```bash
   # Stop Redis
   # Replace dump.rdb with backup
   cp /backup/dump.rdb /data/dump.rdb
   # Start Redis
   ```

2. **From AOF**:
   ```bash
   # Check AOF integrity
   redis-check-aof appendonly.aof
   
   # Fix corrupted AOF
   redis-check-aof --fix appendonly.aof
   
   # Restart Redis
   ```

3. **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

```bash
# 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

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

### Performance Optimization

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

### Monitoring

1. **Watch Last Save Time**: Ensure snapshots completing
2. **Monitor File Sizes**: Catch runaway growth
3. **Check Rewrite Status**: Ensure rewrites succeeding
4. **Alert on Failures**: Immediate notification on issues
5. **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**:
```bash
# 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**:
```bash
# 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**:
```bash
# 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:

```bash
# 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

## Related Documentation

- [Redis Overview](https://docs.danubedata.ro/cache-redis)
- [Redis Replicas](https://docs.danubedata.ro/cache-replicas)
- [Cache Monitoring](https://docs.danubedata.ro/cache-monitoring)
- [Database Backups](https://docs.danubedata.ro/databases-backups)
- [Platform SLA](https://docs.danubedata.ro/platform-sla)