DHIVA LABS · LEARN

Appearance

Schedule backups ​

One backup cycle (copy, encrypt, verify, then prune old backups) is a single --once run. To back up daily, something must start that run every day. There are three ways, in order of preference.

MethodStarts the runCatches up after downtime
systemd timer (recommended)systemd, at the time in the .timer fileYes
croncron, at the time in the crontabNo
--daemonthe tool's own scheduler, at schedule_timeNo

Use only one method. Two schedules on the same database and folder can run at the same time, and each run starts by deleting .partial files it finds in the destination folder, including another run's work in progress.

With the systemd timer ​

The repository's systemd/lmdb-lws-backup.service runs one --once cycle; systemd/lmdb-lws-backup.timer starts it daily at 03:00 with up to 5 minutes of random delay. Persistent=true makes systemd run a missed backup at the next boot.

  1. Make sure /etc/lmdb-lws-backup/key.env and /etc/lmdb-lws-backup/config.toml exist. See the beginner guide.

  2. Copy the units and reload systemd:

    bash
    sudo cp systemd/lmdb-lws-backup.service systemd/lmdb-lws-backup.timer /etc/systemd/system/
sudo systemctl daemon-reload

  3. Enable and start the timer:

    bash
    sudo systemctl enable --now lmdb-lws-backup.timer

  4. Check when it runs next:

    bash
    systemctl list-timers lmdb-lws-backup.timer

See the results of past runs with journalctl -u lmdb-lws-backup.service.

Adapt the service to your system ​

The service is written for the monero-lws defaults. Edit /etc/systemd/system/lmdb-lws-backup.service if yours differ, then run sudo systemctl daemon-reload:

SettingDefaultChange it to
User, Groupmonero-lwsThe user that owns the database. It needs write access to lock.mdb.
ExecStart/usr/local/bin/lmdb-lws-backup --config /etc/lmdb-lws-backup/config.toml --onceYour binary and configuration paths.
BindPathsthe monero-lws database folderYour db_path folder. The unit hides /home, so a database under /home must be listed here.
ReadWritePaths/var/backups/monero-lws /var/log/lmdb-lws-backup.logYour destination_dir and log_path. The service cannot write anywhere else.
EnvironmentFile/etc/lmdb-lws-backup/key.envWhere your key file is.

The paths in BindPaths and ReadWritePaths must exist before the service starts, and the service user must have write permission on them.

Change the time ​

Edit OnCalendar=*-*-* 03:00:00 in the .timer file, then run sudo systemctl daemon-reload and sudo systemctl restart lmdb-lws-backup.timer. The schedule_time setting in the configuration is not used by the timer.

With cron ​

cron has no equivalent of systemd's EnvironmentFile, so use a key file:

  1. Create a key file owned by the backup user, as shown in Keys and security, and set it in the configuration. Remove key_env_var: only one key source is allowed.

    toml
    [encryption]
key_file = "/etc/lmdb-lws-backup/backup.key"

  2. Give the backup user write access to the destination folder, the log file and the database's lock.mdb. For monero-lws, run cron as the monero-lws user, or put the backup user in the monero-lws group and make lock.mdb group-writable.

  3. Edit that user's crontab:

    bash
    sudo crontab -u monero-lws -e

    Add a line for 03:00 every day:

    text
    0 3 * * * /usr/local/bin/lmdb-lws-backup --config /etc/lmdb-lws-backup/config.toml --once

With the built-in daemon ​

For systems without systemd timers or cron, --daemon keeps running and starts a cycle every day at schedule_time:

toml
[backup]
schedule_time = "03:00"   # HH:MM, 24-hour
timezone = "UTC"          # "UTC", "local", or an IANA name such as "Europe/Berlin"

The repository includes systemd/lmdb-lws-backup-daemon.service as an example of running it. The daemon:

  • waits for the next schedule_time after it starts; it does not run a backup immediately, and does not catch up on runs missed while it was stopped;
  • keeps running when a backup fails, logs the error, calls the failure webhook if configured, and tries again the next day;
  • shuts down cleanly on SIGTERM or SIGINT, abandoning a backup in progress without replacing the previous good one.

Things to know about any schedule ​

  • Dates in file names use the timezone setting (UTC by default), for --once as well as --daemon. A run at 03:00 local time may therefore carry the previous or next day's UTC date.
  • Running twice on one day replaces that day's backup, but only after the new one has passed verification.
  • The database may grow during a long backup. While the snapshot is open, LMDB cannot reuse freed pages, so data.mdb can grow. The space is reused afterwards.
  • Old backups are pruned only after a new one succeeds. See Retention.

Next steps ​