Great question! Since Neo4j's native online backup is an Enterprise-only feature, let's walk through what you can do with the Community Edition, along with the tradeoffs and best practices you need to know.

Do I have to stop the database to run a dump? #

Short answer: If you want a consistent, recoverable backup, yes—you should stop the database first when using the built-in neo4j-admin dump tool in Community Edition.

When the database is running, neo4j-admin dump reads the data files as they are, but there's no guarantee of transactional consistency. You might end up with a backup where half a transaction is written, or relationships are incomplete. Restoring from such a backup could lead to a corrupted database that won't start, or data inconsistencies that are hard to debug.

That said, there are workarounds to minimize downtime (more on that in the backup tips below).

What happens if I run a dump while the database is running? #

Running neo4j-admin dump on a live Community Edition instance has a few key impacts:

• Performance hit: The dump process reads every data file, which will spike IO usage. This can slow down queries and writes for your end users.
• Inconsistent backup: As mentioned, the backup won't be transactionally consistent. You might not notice this until you try to restore, which could be catastrophic if you're relying on it for disaster recovery.
• Potential instability: In rare cases, the heavy IO load from the dump could cause the database to become unresponsive, especially if your server has limited resources.

How can I set up automated backups for Community Edition? #

Since there's no native online backup, you'll need to combine neo4j-admin dump with automation tools to create scheduled backups. Here's the core approach:

1. Use a script to stop the database, run the dump, then restart the database.
2. Schedule this script with a task scheduler (like cron on Linux or Task Scheduler on Windows) to run at regular intervals (e.g., daily during off-peak hours).

Here's an example bash script you can adapt:

#!/bin/bash
BACKUP_DIR="/path/to/your/backups"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="${BACKUP_DIR}/neo4j_backup_${DATE}.dump"

# Stop Neo4j to ensure consistency
echo "Stopping Neo4j..."
neo4j stop

# Wait a few seconds to ensure the process exits
sleep 5

# Run the dump
echo "Creating backup to ${BACKUP_FILE}..."
neo4j-admin dump --database=graph.db --to="${BACKUP_FILE}"

# Start Neo4j back up
echo "Starting Neo4j..."
neo4j start

# Optional: Verify the backup (load into a test database)
echo "Verifying backup..."
neo4j-admin load --database=backup_test --from="${BACKUP_FILE}" --force
neo4j start --database=backup_test
# Run a quick validation query (adjust as needed)
cypher-shell -u neo4j -p your_password -d backup_test "MATCH (n) RETURN count(n) as node_count"
neo4j stop --database=backup_test
neo4j-admin drop --database=backup_test

# Optional: Clean up old backups (keep last 7 days)
echo "Cleaning up old backups..."
find "${BACKUP_DIR}" -name "neo4j_backup_*.dump" -mtime +7 -delete

echo "Backup process completed successfully!"

Backup Tips for Neo4j 3.x Community Edition #

• Use file system snapshots for minimal downtime: If your server uses a snapshot-capable file system (like LVM, ZFS, or AWS EBS snapshots), you can:
  1. Temporarily set the database to read-only (dbms.read_only=true in neo4j.conf, then restart or apply the setting dynamically if supported).
  2. Take a snapshot of the Neo4j data directory.
  3. Re-enable write access.
  4. Mount the snapshot and run neo4j-admin dump from the mounted snapshot. This way, you only have a read-only window instead of a full stop.
• Validate backups every time: It's useless to have backups you can't restore. Always test loading the backup into a separate database to ensure it works.
• Store backups offsite: Don't keep backups on the same server as the database. Use cloud storage or a separate network drive to avoid losing both the database and backups in case of hardware failure.
• Encrypt sensitive backups: If your data contains sensitive information, encrypt the dump files before storing them. You can use tools like gpg for this.
• Schedule backups during off-peak hours: Pick a time when your database has the least traffic to minimize the impact on users, even if you have to stop the database briefly.

内容的提问来源于stack exchange，提问作者Aerodynamika