Backup and monitoring

What is in the data directory

The data directory is set by data_dir in the config file (by default, ./data under the working directory). Below, it’s written as $DATA_DIR.

Item	Back it up?	Description
rerinkuview.db (and its -wal and -shm files)	Required	SQLite database: devices, groups, settings, events, the access password, phone bindings and this Rerinku View’s instance ID
secret.key	Required	32-byte encryption key. Camera passwords and the credentials for remote storage, Quick Connect and MQTT are all encrypted with it, and device tokens are issued with it too
config.yaml	Required	The config file. It’s in the working directory, not in $DATA_DIR. Ports and GB28181 parameters are stored only here
recordings/	As needed	Recording files. The files themselves are the source of truth for recordings; the recording index in the database can be rebuilt from them
models/, faces/	If you use AI recognition	Recognition models and face library photos
cloud/	No	Quick Connect runtime files; they’re regenerated
~/.rerinku/bin/	No	The built-in FFmpeg and recognition component, unpacked automatically on every start

Always back up secret.key together with the database. Without it, every camera needs its password entered again after a restore, and the Quick Connect, remote storage and MQTT credentials need to be set up again. Watch out: if Rerinku View can’t find secret.key at startup, it just generates a new one without reporting an error.

Backup

Recommended: stop the service and copy everything

1. Stop Rerinku View and make sure the process has exited. On a normal stop, recording files that are being written are finalized.
2. Copy the data directory and the config file into a timestamped directory, generate checksums, and tighten permissions:

export DATA_DIR=/var/lib/rerinku-view/data
export BACKUP_DIR=/srv/backups/rerinku-$(date -u +%Y%m%dT%H%M%SZ)
mkdir -p "$BACKUP_DIR"
cp -a "$DATA_DIR" /var/lib/rerinku-view/config.yaml "$BACKUP_DIR/"
(cd "$BACKUP_DIR" && find . -type f ! -path './data/recordings/*' -exec sha256sum {} + > SHA256SUMS)
chmod -R go-rwx "$BACKUP_DIR"

Online backup

If you don’t want to stop the service, back up the database with SQLite’s backup command. Don’t copy a database file directly while it’s being written. Copy secret.key and the config file directly:

sqlite3 "$DATA_DIR/rerinkuview.db" ".backup '$BACKUP_DIR/rerinkuview.db'"
cp -a "$DATA_DIR/secret.key" /var/lib/rerinku-view/config.yaml "$BACKUP_DIR/"

Recording files that have been finalized never change again, so you can sync them incrementally online with a tool such as rsync.

Restore and migration

1. Stop Rerinku View. If you’re recovering from a failure, keep a copy of the current data first. Don’t overwrite the only copy of what’s there.
2. Put the backed-up data directory and config file back in place, and make sure the user running Rerinku View can read and write them.
3. Check the database before starting: sqlite3 "$DATA_DIR/rerinkuview.db" 'PRAGMA integrity_check;'
4. Start the same or a newer version, then check /healthz, the device list and at least one historical playback.

Migrating to a new machine takes the same steps. In addition:

• Anywhere the config file has the old machine’s IP written in (rerinku_device.public_url, public_mqtt_broker), change it to the new address.
• Don’t run the old and new machines at the same time. The database carries the instance ID, so the copied Rerinku View and the original are “the same one”: Quick Connect and bound phones treat them as one.

Upgrade

The complete procedure is now in Updating and rollback. Back up the database, secret.key and configuration first; rollback requires the database backup from before the update.

Rollback

Follow the rollback procedure to restore an earlier version. Replacing the executable alone is not sufficient.

Monitoring

Health check

GET /healthz

Returns 200 and {"status":"ok"} when the database is working, otherwise 503. It needs no authentication. We recommend requesting it every 30 seconds and alerting on consecutive failures.

System resources

GET /api/v1/system/resources returns CPU, memory, GPU, network, temperature and disk status (sampled every 2 seconds), along with an overall status:

Metric	Warning	Critical
CPU (1-minute average)	90%	—
Memory	90%	95%
Disk	95%	98%
Temperature	85 ℃	95 ℃

This endpoint needs a token when Rerinku View is reachable from outside this machine. See Open API.

Logs

Logs are written to standard output as JSON. Rerinku View doesn’t rotate logs itself; leave that to systemd, the container runtime or your log platform. Logs include device IDs and addresses for troubleshooting, but never camera passwords or addresses that contain credentials.

We recommend alerting on these strings:

String	Meaning
recording error	A recording error
recording storage check failed	Checking recording storage failed
recordings paused to protect storage	Disk space is low and recording is paused; it resumes automatically once space is available again
removing recording that has not been uploaded yet	A recording that hadn’t finished uploading to remote storage was removed
application stopped	Rerinku View has stopped

Rerinku View currently has no Prometheus metrics endpoint.

Debug interface

When APP_ENV is development (the default), Rerinku View opens Go’s pprof debug interface on 127.0.0.1:6060. It’s reachable only from this machine. For production use, we recommend setting APP_ENV=production to turn it off. See Configuration reference.