Skip to content

Where your data lives

The bark monitor stores everything in a single SQLite database, recording.db, inside your output folder (by default the folder you configured in the config file).

What is in recording.db

The database is an append-only event log: every bark, every activity detected, and every start/stop of the recorder is one event. Events are never modified or deleted after being written.

Each event carries a hash that covers the event itself and the hash of the previous event, forming a tamper-evident hash chain. If anyone edits or deletes a row after the fact, the chain stops verifying. This is what makes the recorded history usable as evidence: you can show the recorded barking seconds are exactly what the device measured, and a simple verification re-computes the whole chain.

The monitor also keeps a small aggregate table (barking seconds per day) so the bots and the web API can answer "how long did the dog bark today" without scanning the whole log.

Data layout

  • recording.db — the event store (the source of truth).
  • recording.db-wal / recording.db-shm — SQLite housekeeping files, safe to ignore, they disappear when the monitor stops cleanly.
  • recordings/ — the audio files of the barking events, if you record audio at all.

Back up or sync recording.db — that single file is your history. The sync options upload exactly this file.

Coming from an older version (automatic migration)

Older versions of the bark monitor stored their state in a recording.json file. You do not need to do anything: when the monitor starts and finds a legacy recording.json next to the database (or one downloaded from a sync service), the whole history is migrated into the event store once, automatically. The legacy file is left in place untouched, and re-running the migration can never duplicate history.

Sync and backup

recording.db is the only file that needs backing up, and every sync service uploads exactly it:

  • Nextcloud sync — recommended: the database file is uploaded after every change, and a remote legacy recording.json (if present) is merged in on start.
  • Google drive sync — same behaviour, experimental.
  • Hosted cloud sync — the hosted dashboard mirrors the events (not the raw file) over the network, and re-verifies the hash chain of everything it receives.

Audio recordings are a separate concern: they are zipped and uploaded as bark_monitor_audio.zip overwriting any previously uploaded archive (there is no merging for audio, so keep old archives if you care about them).