Add comprehensive durability documentation

[shahar-biron]

Summary

This PR adds comprehensive durability documentation for FalkorDB and reorganizes the navigation structure.

Changes

• New file: durability.md - Comprehensive guide covering:

  • RDB (Redis Database) snapshots with configuration examples
  • AOF (Append-Only File) persistence with fsync policies
  • Graph-specific DUMP/RESTORE operations
  • Strategy recommendations for different use cases
  • Performance considerations and best practices

• Navigation reorganization:

  • persistence.md is now a child page of durability.md
  • Updated index.md to reflect the new structure
  • Added cross-references between guides

Documentation Structure

Operations
└── Durability (durability.md)
    └── Persistence on Docker (persistence.md)

References

• Incorporates information from Redis persistence tutorials
• Links to official Redis DUMP/RESTORE command documentation
• Cross-references FalkorDB-specific guides

Co-Authored-By: Warp agent@warp.dev

Summary by CodeRabbit

• Documentation
  • Added a comprehensive Data Durability guide covering RDB/AOF mechanisms, trade-offs, backup and restore strategies, monitoring, and best practices for varied workloads.
  • Reorganized operations docs and navigation to surface durability topics and linked related guidance (including Docker persistence and graph-specific backup notes).
  • Included example configurations, command usage, and recommendations for choosing durability strategies.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

PR Summary by Typo

Overview

This pull request introduces comprehensive documentation on data durability for FalkorDB, explaining various persistence mechanisms and best practices for ensuring data safety.

Key Changes

A new durability.md document details RDB snapshots, AOF logging (including fsync policies), combining persistence methods, and graph-specific DUMP/RESTORE commands. The operations/index.md was updated to reflect the new documentation structure, and operations/persistence.md was refined to focus on Docker persistence and cross-reference the new durability guide. New terms like fsync, cron, and everysec were added to the wordlist.

Work Breakdown

Category	Lines Changed
New Work	275 (98.2%)
Rework	5 (1.8%)
Total Changes	280

To turn off PR summary, please visit Notification settings.

[coderabbitai]

📝 Walkthrough

Walkthrough

A new Data Durability guide was added to operations, the operations index was updated to link to it, and the existing Persistence doc was refocused on Docker persistence with cross-references to the new durability documentation.

Changes

Cohort / File(s)	Summary
Durability guide & index operations/durability.md, operations/index.md	Added durability.md documenting RDB snapshots, AOF logging, fsync policies, AOF rewrite, DUMP/RESTORE for graphs, examples, Docker persistence notes, monitoring, and backups; index entry renamed/linked to "Data Durability" and descriptive text updated.
Persistence (Docker-focused) operations/persistence.md	Updated frontmatter/title to "Persistence on Docker", adjusted nav order and parent metadata, added "Understanding Durability Options" section and cross-reference to operations/durability.md; content reflowed for Docker emphasis.
Wordlist additions .wordlist.txt	Appended three tokens: fsync, cron, everysec.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 I hopped through docs to make things clear,
RDB, AOF — durability's near,
Docker kept safe, graphs backed up tight,
Cross-links gleam in the docs tonight,
🥕📚✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Add comprehensive durability documentation' directly and accurately describes the main change—adding a new durability.md guide that covers RDB, AOF, and related persistence mechanisms, along with reorganizing the documentation structure.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@operations/durability.md`:
- Around line 96-106: Add the technical tokens that the spellchecker is flagging
to the project's spellcheck allowlist: include "everysec", "cron" and any HTML
tag-like tokens such as "html>body>h3" (or add a rule to ignore tokens
containing ">" or HTML tag patterns). Update the CI spellcheck dictionary/config
used by the repo so these terms are whitelisted, and ensure the change covers
the occurrences in the durability documentation (the `appendfsync everysec`
section and the other flagged lines). Run the spellcheck locally or in CI to
verify the job no longer fails.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Fix spellcheck pipeline failures by whitelisting technical terms.

everysec and cron are legitimate terms (and appear in config/examples), but the spellcheck job is flagging them. Add them to the project’s spellcheck allowlist (and consider ignoring HTML tag tokens like html>body>h3 that the tool is surfacing). This will unblock CI while keeping the wording intact.

Also applies to: 247-251

🤖 Prompt for AI Agents

In `@operations/durability.md` around lines 96 - 106, Add the technical tokens
that the spellchecker is flagging to the project's spellcheck allowlist: include
"everysec", "cron" and any HTML tag-like tokens such as "html>body>h3" (or add a
rule to ignore tokens containing ">" or HTML tag patterns). Update the CI
spellcheck dictionary/config used by the repo so these terms are whitelisted,
and ensure the change covers the occurrences in the durability documentation
(the `appendfsync everysec` section and the other flagged lines). Run the
spellcheck locally or in CI to verify the job no longer fails.

[augmentcode]

🤖 Augment PR Summary

Summary: Adds a new Operations “Durability” guide to explain how FalkorDB data survives restarts/failures, and reorganizes the Operations navigation accordingly.

Changes:

• Introduces operations/durability.md covering Redis-backed durability concepts (RDB snapshots and AOF persistence).
• Documents AOF appendfsync policies and AOF rewrite/maintenance commands.
• Adds guidance on combining RDB + AOF and choosing configurations based on performance vs. data-loss tolerance.
• Includes a section on graph-level backup/migration using Redis DUMP/RESTORE (per-key export).
• Links durability guidance to Docker persistence setup and related Operations guides (Replication, etc.).
• Re-nests operations/persistence.md as a child page under Durability (“Persistence on Docker”) via front-matter hierarchy.
• Updates operations/index.md TOC entry from “Configuring Persistence” to “Data Durability” to match the new structure.

Technical Notes: Uses Just-the-Docs front matter (has_children, parent, grand_parent, nav_order) to create an Operations → Durability → Persistence navigation tree.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 2 suggestions posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

redis-cli DUMP returns an opaque binary payload, and redis-cli’s default output formatting/quoting isn’t generally safe to redirect into a file and replay later; as written, the DUMP/RESTORE examples here are likely to fail or produce corrupted dumps. Consider clarifying the binary-safety/encoding requirements for a reliable graph export/import flow.

Other Locations

• operations/durability.md:163
• operations/durability.md:165

_{🤖 Was this useful? React with 👍 or 👎}

[augmentcode]

For appendfsync always, Redis typically only acknowledges the write after it has been fsync’d, so describing the risk as “Only the latest command” may be misleading (it should be ~0 for acknowledged writes, barring hardware/FS failures). Consider tightening this wording so readers don’t overestimate expected data loss for this mode.

_{🤖 Was this useful? React with 👍 or 👎}

[typo-app]

Static Code Review 📊

✅ All quality checks passed!

[typo-app]

AI Code Review 🤖

Files Reviewed: 4
Comments Added: 0
Lines of Code Analyzed: 285
Critical Issues: 0

PR Health: Excellent 🔥

_{Give 👍 or 👎 on each review comment to help us improve.}