Durability

FalkorDB, built on Redis, provides multiple mechanisms for data durability to ensure your graph data persists across restarts and survives system failures. Understanding these options helps you balance performance requirements with data safety needs.

Overview

FalkorDB supports two primary persistence mechanisms:

RDB (Redis Database) - Point-in-time snapshots
AOF (Append-Only File) - Operation logging

You can use either mechanism independently or combine both for enhanced durability.

RDB Snapshots

How RDB Works

RDB creates point-in-time snapshots of your entire dataset and writes them to a compact .rdb file on disk. This approach provides:

Compact, single-file backups ideal for disaster recovery
Fast restart times (faster than AOF for large datasets)
Easy versioning and cloning of datasets

RDB Configuration

Configure RDB through redis.conf or via redis-cli:

# Save the dataset every 60 seconds if at least 1000 keys changed
save 60 1000

# Save every 5 minutes if at least 100 keys changed
save 300 100

# Save every 15 minutes if at least 1 key changed
save 900 1

# Configure RDB file location and name
dir /var/lib/falkordb/data
dbfilename dump.rdb

RDB Considerations

Advantages:

Excellent for backups and disaster recovery
Minimal impact on performance during normal operations
Compact file format
Fast data loading on restart

Limitations:

Potential data loss between snapshots
Forking can be time-consuming for large datasets
May cause brief performance degradation (milliseconds to 1 second) during snapshot creation on very large datasets
Requires significant disk I/O during snapshot operations

Best for: Use cases where losing a few minutes of data is acceptable, or as a backup mechanism alongside AOF.

AOF (Append-Only File)

How AOF Works

AOF logs every write operation as it happens, creating an append-only log that can replay all operations to reconstruct the dataset. This provides greater durability than RDB snapshots.

AOF Configuration

# Enable AOF
appendonly yes

# AOF file location
appendfilename "appendonly.aof"

# fsync policy - choose one:
appendfsync always    # Safest but slowest
appendfsync everysec  # Good balance (default)
appendfsync no        # Fastest but less durable

AOF fsync Policies

1. `appendfsync always`

Durability: Maximum - virtually no data loss
Performance: Lowest - synchronous disk writes
Data Loss Risk: Only the latest command in case of disaster
Best for: Mission-critical data where no data loss is acceptable

2. `appendfsync everysec` (Recommended)

Durability: High - fsync performed asynchronously every second
Performance: High - background thread handles disk writes
Data Loss Risk: Up to 1 second of writes
Best for: Most production use cases balancing performance and durability

3. `appendfsync no`

Durability: Depends on OS (typically 30 seconds on Linux)
Performance: Highest - OS decides when to flush
Data Loss Risk: Several seconds of data in case of crashes
Best for: High-performance scenarios where some data loss is acceptable

AOF Rewrite

Over time, AOF files can grow large. AOF rewrite creates a compact version:

# Automatically trigger rewrite when file grows 100% larger
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Manual rewrite:

redis-cli BGREWRITEAOF

Combining RDB and AOF

For maximum durability, enable both mechanisms:

# Enable both persistence methods
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

On restart, FalkorDB will use the AOF file (if available) since it provides better durability guarantees.

Graph-Specific Operations: DUMP and RESTORE

For graph-specific backup and migration scenarios, FalkorDB supports Redis’s DUMP and RESTORE commands for individual keys (graphs).

DUMP Command

Serialize a graph to a portable format:

redis-cli DUMP mygraph > mygraph.dump

The DUMP command:

Returns a serialized representation of the value at the specified key
The serialization format is opaque and specific to Redis/FalkorDB
Contains the graph structure and all its data
Does not include TTL information by default

Learn more: Redis DUMP Documentation

RESTORE Command

Restore a serialized graph:

redis-cli --pipe < mygraph.dump
# Or directly:
redis-cli RESTORE mygraph 0 "<serialized-value>"

RESTORE options:

REPLACE - Overwrite existing key (available since Redis 3.0.0)
ABSTTL - TTL represents absolute Unix timestamp (since Redis 5.0.0)
IDLETIME - Set the idle time for the object

Learn more: Redis RESTORE Documentation

Use Cases for DUMP/RESTORE

Selective backup: Back up specific graphs rather than entire database
Migration: Move specific graphs between FalkorDB instances
Testing: Clone production graphs to test environments
Archival: Export graphs for long-term storage

Note: For full database backup, RDB snapshots are more efficient than individual DUMP operations.

Choosing the Right Strategy

High Performance, Some Data Loss Acceptable

save 900 1
save 300 10
appendonly no

Balanced Performance and Durability (Recommended)

save 900 1
save 300 10
save 60 1000
appendonly yes
appendfsync everysec

Maximum Durability

save 60 1
appendonly yes
appendfsync always

Development/Testing

save ""
appendonly no

Docker Environment Persistence

When running FalkorDB in Docker, proper volume configuration is essential for durability. See the Persistence on Docker guide for detailed instructions on:

Creating persistent volumes
Mounting data directories
Verifying persistence configuration
Best practices for Docker deployments

For persisting ACL users (so users created with ACL SETUSER survive container restarts), see ACL Persistence on Docker.

Monitoring and Maintenance

Check Persistence Status

redis-cli INFO persistence

Manual Save Operations

# Create RDB snapshot immediately (blocking)
redis-cli SAVE

# Create RDB snapshot in background (non-blocking)
redis-cli BGSAVE

# Rewrite AOF file
redis-cli BGREWRITEAOF

Backup Best Practices

Regular Snapshots: Schedule periodic RDB snapshots using cron or similar
Off-site Backups: Store backups in separate locations or cloud storage
Test Restores: Regularly verify backups can be restored successfully
Monitor Disk Space: Ensure sufficient space for both RDB and AOF files
Automate: Use scripts to automate backup, verification, and rotation

Performance Considerations

RDB: Brief CPU spike and memory overhead during fork; negligible impact between snapshots
AOF (everysec): Minimal performance impact, ~1-2% overhead
AOF (always): Significant performance impact due to synchronous disk I/O
Both RDB + AOF: Cumulative overhead but maximum durability

Frequently Asked Questions

Should I use RDB or AOF for FalkorDB persistence?

For most production use cases, use both. RDB provides fast restarts and compact backups, while AOF (appendfsync everysec) ensures at most 1 second of data loss. Combined, they offer maximum durability.

What is the recommended fsync policy for AOF?

Use appendfsync everysec (the default). It provides a good balance between performance and durability with minimal overhead (~1-2%). Use always only for mission-critical data where zero data loss is required.

How do I back up a specific graph without snapshotting the entire database?

Use the Redis DUMP command on the graph key: redis-cli DUMP mygraph > mygraph.dump. This serializes just that graph for selective backup, migration, or archival.

Does RDB snapshot creation affect query performance?

Briefly, yes. RDB uses fork() which causes a short performance degradation (milliseconds to ~1 second) on very large datasets. Between snapshots, there is no impact on normal operations.

How do I verify my persistence configuration is working?

Run redis-cli INFO persistence to check RDB and AOF status. Look for rdb_last_save_time, aof_enabled, and aof_last_rewrite_status fields to confirm both mechanisms are active.

Home

Overview

RDB Snapshots

How RDB Works

RDB Configuration

RDB Considerations

AOF (Append-Only File)

How AOF Works

AOF Configuration

AOF fsync Policies

1. `appendfsync always`

2. `appendfsync everysec` (Recommended)

3. `appendfsync no`

AOF Rewrite

Combining RDB and AOF

Graph-Specific Operations: DUMP and RESTORE

DUMP Command

RESTORE Command

Use Cases for DUMP/RESTORE

Choosing the Right Strategy

High Performance, Some Data Loss Acceptable

Balanced Performance and Durability (Recommended)

Maximum Durability

Development/Testing

Docker Environment Persistence

Monitoring and Maintenance

Check Persistence Status

Manual Save Operations

Backup Best Practices

Performance Considerations

Further Reading

Frequently Asked Questions

​Overview

​RDB Snapshots

​How RDB Works

​RDB Configuration

​RDB Considerations

​AOF (Append-Only File)

​How AOF Works

​AOF Configuration

​AOF fsync Policies

​1. appendfsync always

​2. appendfsync everysec (Recommended)

​3. appendfsync no

​AOF Rewrite

​Combining RDB and AOF

​Graph-Specific Operations: DUMP and RESTORE

​DUMP Command

​RESTORE Command

​Use Cases for DUMP/RESTORE

​Choosing the Right Strategy

​High Performance, Some Data Loss Acceptable

​Balanced Performance and Durability (Recommended)

​Maximum Durability

​Development/Testing

​Docker Environment Persistence

​Monitoring and Maintenance

​Check Persistence Status

​Manual Save Operations

​Backup Best Practices

​Performance Considerations

​Further Reading

​Frequently Asked Questions

Overview

RDB Snapshots

How RDB Works

RDB Configuration

RDB Considerations

AOF (Append-Only File)

How AOF Works

AOF Configuration

AOF fsync Policies

1. `appendfsync always`

2. `appendfsync everysec` (Recommended)

3. `appendfsync no`

AOF Rewrite

Combining RDB and AOF

Graph-Specific Operations: DUMP and RESTORE

DUMP Command

RESTORE Command

Use Cases for DUMP/RESTORE

Choosing the Right Strategy

High Performance, Some Data Loss Acceptable

Balanced Performance and Durability (Recommended)

Maximum Durability

Development/Testing

Docker Environment Persistence

Monitoring and Maintenance

Check Persistence Status

Manual Save Operations

Backup Best Practices

Performance Considerations

Further Reading

Frequently Asked Questions