Rsync Block Level
You run an rsync block level transfer by comparing file chunks between two hosts. The tool reads both files, finds altered parts, and sends only the changed blocks. Engineering teams use this method to move large backups and database files across servers. To make transfers run without prompts, admins often set up broad root SSH keys. When those keys have wide permissions, any user with the key can alter production data. How an rsync block level transfer works Standard file copy tools move the
Board-Level Security Reporting: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You run an rsync block level transfer by comparing file chunks between two hosts. The tool reads both files, finds altered parts, and sends only the changed blocks. Engineering teams use this method to move large backups and database files across servers. To make transfers run without prompts, admins often set up broad root SSH keys. When those keys have wide permissions, any user with the key can alter production data.
How an rsync block level transfer works
Standard file copy tools move the entire file every time you make a change. This wastes network bandwidth when you update a small part of a huge file. The rsync block level process fixes this problem by splitting files into fixed chunks. First, the tool checks the file size and last change time on both machines. If those values match, the tool skips the file and moves to the next one.
When a file changes, the receiving host breaks its old copy into small blocks. It calculates two math checksums for each block and sends that list to the sender. A fast rolling checksum helps find blocks that shifted position inside the updated file. A strong second checksum confirms that two blocks hold the exact same bytes of data.
The sending host reads the new file byte by byte and compares the checksums. When it finds a matching block, it sends a short note instead of raw data. When it finds new bytes, it sends only those fresh bytes over the network. The receiving host uses its old blocks and the new bytes to build the file. It writes this new copy to a temp file and swaps it in at the end.
Why local transfers act differently than network syncs
Many admins get surprised when local disk copies do not use the delta algorithm. When both folders sit on the same machine, the tool copies the whole file. Reading and hashing blocks takes more processor time than writing a fresh local copy. Over a slow network link, checking blocks saves huge amounts of transfer time. The tool switches to block comparisons on its own when it runs over a network.
Board-Level Security Reporting: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native file sync solves and what it leaves open
Native file sync tools solve the problem of moving large files over slow links. They pair with SSH keys to verify which machine or user can log in. This setup protects data in transit and stops strangers from entering the host. Still, host login checks only decide who gets into the server at the start. Once a session begins, the sync tool runs with the full rights of that account.
Teams often grant broad read and write roles so automated sync jobs do not fail. If an engineer or script targets the wrong folder, it can wipe out good files. Host logs show that an SSH login happened, but they miss the exact file path. Also, syncing raw database dumps can move private card numbers or emails to test hosts. Native file transfer tools cannot inspect data in flight or block bad commands before execution.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Does rsync always use the block delta algorithm?
No, it only uses block transfers when sending files across a network to another host. For local disk copies, it moves the whole file to save processor work.
Can rsync update open database files safely?
Copying a live database file during writes can create a broken copy on the target. You should take a clean database snapshot first and then sync that static file.
Why does a block transfer take high disk read time?
Both hosts must read the full file from disk to calculate block checksums in memory. This saves network bandwidth, but it still puts heavy read load on both storage drives.