That’s correct. UrBackup is designed not to transfer or store files more then once. An “incremental” backup relies on the Client program to identify which files are changed. A “full” backup tells the Client to send hashes for all files and let the Server request which files need to be completely sent because they are not already present in the bulk store.
UrBackup separates the file “bits” from the directory “metadata” and uses some smart programming to allow browsing any backup as if it were a full copy of the client’s filesystem. [This also leads to various tools claiming the files consume more or less storage than expected because they count things differently.] This standard file-level deduplication is joined by using advanced operating system features to compress or deduplicate individual blocks of data when such features are available.
Example: If everyone in the office has a read-only copy of the 1000-page policy manual, then UrBackup can keep one copy and reference that unchanging copy in each backup performed. The committee which is revising the policy manual can pass around chapters for comment and, if supported by the server operating system and storage, only altered blocks of the giant file will be recorded with each round of changes. Restoring a single file or entire directory at any point reassembles the pieces into a new file or directory which exactly matches the original at the selected point in time.
The result is you get more backups that take less time to perform, so backing up frequently is not much of a burden.