Documentation — TripleGuard

Installing the agent

The agent runs as a service and keeps its state in /var/lib/tguard on Linux, %ProgramData%\TripleGuard on Windows.

Linux

curl -fsSL https://get.tripleguard.ru/install.sh | sh
tguard init --regions eu-north,eu-central

The script adds the apt or rpm repository and installs tguard 3.8.2. For hosts without outbound internet access, download the .deb or .rpm from the downloads page and install it by hand.

Windows

Run the MSI as administrator. The installer registers the TripleGuard Agent service and adds tguard.exe to PATH. Silent install for deployment tools:

msiexec /i tripleguard-agent-3.8.2.msi /qn TOKEN=<account token>

macOS

Mount the DMG and drag TripleGuard to Applications. On first launch macOS asks for full disk access — without it the agent cannot read Mail and Photos libraries.

Schedules

A job is a folder, a schedule and a list of regions. Jobs are independent: one can run hourly to a single region while another runs weekly to all three.

tguard add /srv/projects --schedule hourly --regions eu-north
tguard add /var/lib/postgresql --schedule "*/15 * * * *" --pre-hook /usr/local/bin/pgdump.sh
tguard limit --upload 20Mbit --window 09:00-18:00
tguard list

Upload limits apply per machine, not per job. Outside the window the agent uses whatever bandwidth is available; a 250 GB first copy on a 100 Mbit line takes roughly six hours.

Retention

Preset	Keeps
short	24 hourly, 7 daily, 4 weekly
standard	24 hourly, 30 daily, 12 weekly, 12 monthly
archive	30 daily, 52 weekly, 60 monthly, 10 yearly

Restoring

Every restore point can be mounted read-only, which is usually faster than a full restore when you need a handful of files.

tguard points /srv/projects
tguard mount /srv/projects --at 2026-09-11T22:00 /mnt/restore
cp -a /mnt/restore/site/config.yml /srv/projects/site/
tguard umount /mnt/restore

A full restore to a different machine needs the account token and the encryption key:

tguard restore /srv/projects --at latest --to /srv/projects --key-file ./tguard.key

Keep the key file. Encryption happens on your machine and we hold no copy of the key. If it is lost, the stored data is unreadable — there is no recovery procedure, by design.

Command reference

tguard init — register the machine, pick default regions
tguard add <path> — create a job
tguard rm <path> — remove a job, keep stored data
tguard run <path> — run a job now, ignoring the schedule
tguard pause / tguard resume — stop and start all transfers
tguard points <path> — list restore points
tguard mount / tguard umount — mount a restore point
tguard restore — write files back to disk
tguard verify --deep — re-read checksums from every region
tguard limit — bandwidth windows and caps
tguard status — last run, queue size, next run
tguard logs --since 24h — agent log for support tickets

Troubleshooting

The first copy is slower than expected

Check tguard limit first: a bandwidth window left from testing is the usual cause. Deep directory trees with millions of small files are scanned before transfer starts, which can take an hour on spinning disks.

Verification fails on one region

Run tguard verify --deep --region <name>. Blocks that fail are re-uploaded automatically. If the same block fails twice, open a ticket and attach tguard logs --since 24h.

Agent cannot reach an endpoint

Endpoints listen on 443 only. Corporate proxies that terminate TLS must be listed in proxy.conf, otherwise certificate pinning rejects the connection.