Archiving & recovery

OneSVD fingerprints your tree so you can prove what you're storing, but a single node's fingerprints don't protect you from the node itself failing. If the data matters, you need copies somewhere else. This guide covers the practical approach: replicate to an external node, and keep periodic snapshots you can actually restore from.

Replicate to an external node with rsync#

The simplest durable setup is a second machine that holds a copy of the watched tree. rsync is the right tool — it transfers only what changed, preserves structure, and is safe to run repeatedly.

rsync -avz --delete \
  "$(onesvd dir)/" \
  user@backup-node:~/onesvd-mirror/

If the backup node also runs OneSVD watching that directory (onesvd dir ~/onesvd-mirror), its own watcher fingerprints the replicated tree — so you can compare root hashes between the two nodes to confirm the copy is byte-identical.

Run it on a schedule with cron:

# every 15 minutes
# cron has a minimal PATH, so use the absolute path that `onesvd dir` prints
*/15 * * * * rsync -avz --delete /home/USER/watched/ user@backup-node:~/onesvd-mirror/

Keep daily snapshots with periodic zips#

A mirror protects against hardware failure but not against mistakes — a bad delete or overwrite copies straight to the mirror. For point-in-time recovery, keep dated archives on the external node:

# on the backup node — one zip per day, kept for 30 days
cd ~/onesvd-mirror
zip -rq "$HOME/snapshots/onesvd-$(date +%F).zip" .
find "$HOME/snapshots" -name 'onesvd-*.zip' -mtime +30 -delete

Wire that into cron on the backup node so each day's state is captured after the mirror syncs:

# 03:00 daily, after the night's rsync has run
0 3 * * * ~/snapshot.sh

Now you have two layers: a live mirror that's always current, and a rolling 30 days of snapshots you can restore any single day from.

Restoring#

To restore, stop the node, replace the contents of the watched directory from a snapshot, and start it again:

onesvd stop
rm -rf "$(onesvd dir)"/*
unzip -q ~/snapshots/onesvd-2026-06-20.zip -d "$(onesvd dir)"
onesvd start

The watcher rescans on start, rebuilds the tree, and the root hash will match what that snapshot held — which you can verify against your records.

A note on snapshots and content addressing#

Plain dated zips are simple and reliable, which is why they're recommended here. They're not space-efficient, though — each zip is a full copy, even if little changed since yesterday. Because OneSVD is content-addressed, a future direction is true snapshots that store only changed content and dedupe identical blobs across days, the way Git or a content-addressed backup tool does. Until then, the rotation above (keep N days, prune the rest) keeps disk use bounded, and disk is cheap relative to losing the data.