Continuous backup
A Files job with frequency Continuous does not wait for a schedule: the agent watches the source folders and uploads changes as they happen. It runs in its own lane, so a scheduled job on the same machine is never blocked by it.
How it runs #
- Initial full. When the job is created (or the agent starts), every file is uploaded once, without VSS — a continuous job cannot take a snapshot per change.
- Watch. A filesystem watcher per source path reports created, changed and renamed files. Exclusions, hidden and system rules apply exactly as for a scheduled run.
- Debounce. A change is not uploaded the instant it is seen: the agent waits 30 seconds for the file to stop changing, so a document saved five times in a minute uploads once, and a file being written by a copy uploads when it is complete.
- Upload. The settled file is uploaded, replacing the stored copy (old copies kept if version history is on). A file that is locked is retried every 30 seconds until it can be read.
All of this reports into one long-lived run in Run History: files uploaded, skipped and failed tick up as the day goes on, and the log carries each upload.
When to use it #
For a small working set that changes all day and matters — a firm's live documents, a designer's project folder. Not for a large static archive (the initial full is the same cost, and the watcher then does nothing useful), and not for databases or anything held open all day (the file never settles; use an App-consistent or scheduled VSS job).
Limits #
- Windows, macOS and Linux agents all support it; the watcher is the platform's own (ReadDirectoryChanges, FSEvents, inotify). Very deep trees on Linux can exceed the inotify watch limit; raise
fs.inotify.max_user_watches. - Deletions and moves are not propagated — a renamed file uploads under its new name and the old object stays.
- Network shares watched over SMB report changes made by other machines unreliably; watch on the file server itself.
- Continuous jobs always use conflict policy Replace.
The cloud counterpart — a storage target that reports its own changes — is described under Cloud-to-cloud copy.