The off-site copy that never quite happens
Most teams have a NAS or a file server, a local backup of it, and an intention to keep a copy somewhere else. The copy is the part that slips: a sync tool over TCP to a far-away region takes days for the first run, the office connection cannot be tied up during the day, and nobody can say whether last month’s copy is intact.
Boita is not a backup application. It does not take snapshots, deduplicate or restore a machine bare-metal. It is the fast, verified copy from your server to somewhere else, and on to a second site, that the plan is missing.
What Boita does about it
The headless Linux agent installs in one line on Ubuntu, Debian or RHEL, runs as a systemd service under its own user, and is controlled from the web app. An upload watch folder pointed at the share sends new and changed files once they have stopped changing, in batches, with a rescan every minute; unchanged files are skipped. Allowed hours such as 22:00 to 06:00 keep it off the day’s traffic, and a workspace bandwidth window (a cap during office hours) is enforced by the transfer server, not just the client.
Transfers run over an accelerated transfer engine on UDP with its own rate control, at line rate whatever the distance, and resume after any interruption; completed files are never re-sent. The server records a checksum for every file and shows it in the file details.
A second site, versions and an archive tier
A download watch folder on the agent at a second site pulls anything new or changed onto its own server within a minute, folder layout kept, and never deletes locally. Nothing is deleted on the source either: watch folders do not mirror deletions in either direction. When an upload replaces a file, the previous copy is kept as a version for the retention window and can be restored from Files.
Folders you must keep but rarely open can move to the archive tier with a manifest and restore on demand (Studio and above); Enterprise adds retention rules per folder and a legal hold that stops anything from being deleted for good until it is lifted.
A worked example
A first copy of a 5 TB NAS on Studio, over a 1 Gbps office line, takes about eleven hours, line-limited; run it over a weekend and it is done by Monday. After that, a 200 GB nightly delta on Pro over the same line takes about an hour inside a 22:00 to 06:00 window, plan-limited at 450 Mbps. Distance to the second site does not change these figures on the fast path; loss on the line does, and the calculator on the home page models it.
- Linux agent as a systemd service; watch folders up and down
- Allowed hours per folder; bandwidth windows enforced by the server
- Nothing deleted locally, ever; versions kept for the retention window
- Checksum on every file; delivery receipts as proof
- Archive tier with manifest and restore (Studio and above); retention rules and legal hold (Enterprise)
Proof it happened, and what is coming
Every file shows its server-recorded checksum, the audit log records uploads, downloads and deletions, and a delivery receipt with per-file checksums and a CSV verification report (PDF on Studio and above) is the document for an auditor who asks whether the copy exists and is intact. A Docker image and NAS packages for the agent are coming; today it installs on Ubuntu, Debian or RHEL, x86_64 or arm64, on any server or VM next to the NAS.