Compare · Facts only
NeverWiped and rsync with cron
A cron job with rsync copies files. What it leaves out (encryption at rest, history, consistent databases, alerts), and when it is enough.
A common first backup: a cron job that copies the server’s files to another machine with rsync over SSH. It is simple, and the tools come with every Linux distribution. This page says what it leaves out, what NeverWiped does instead, and when rsync is enough.
What rsync with cron does
- rsync copies files and sends only what changed. Over SSH, the transfer is encrypted.
- The other machine holds plain files. Anyone with access to that machine or its disks can read them, unless you encrypt that disk yourself.
- It keeps one copy, a mirror. A file damaged or deleted on the server is copied as it is at the next run, and with
--deletethe deletions are copied too. A history needs more work: dated folders, or hard links with--link-dest. - The server’s SSH key can write on the other machine, so whoever controls the server can overwrite or delete the copy, unless you restrict that key or pull the files from the other machine instead.
- Copying the files of a running database does not give a consistent copy. You dump it first, in the script.
- A job that fails, or stops running, says nothing unless the server can send mail or you add monitoring.
Side by side
| NeverWiped | rsync with cron | |
|---|---|---|
| Encryption | On your server, before anything is sent; the stored backups are encrypted too (encryption) | During the transfer only (SSH); stored as plain files |
| History | Set by your plan, changeable per server (retention) | One copy, unless you build a rotation |
| A file deleted or damaged by mistake | Still in the earlier backups, until they leave the retention | Copied as it is at the next run |
| Protection against deletion | Append-only storage: the server can add backups, not delete them, day to day (append-only, known limits) | Whatever the SSH key is allowed to do |
| Databases | Full consistent dumps, made by the agent | You script them |
| Space used | Only changes are sent, compressed and deduplicated | Changed files are sent; each rotation adds what changed |
| Alerts | Emails when a backup fails, when none has run for too long, and before the storage is full (alert emails) | You build them |
| Restore | neverwiped restore with a date, into a separate folder, or in place after you confirm (restore) | Copy the files back |
| Where the copy is | Our storage server in France | A machine you choose and look after |
| Price | Your plan (pricing) | The other machine, and your time |
What you build yourself
To make rsync with cron a backup rather than a mirror, you add:
- Dated copies (
--link-dest), and a rule that removes the old ones. - Database dumps before each run.
- Encryption of the other machine’s disk, if the files are sensitive.
- A restricted key, or pulling from the other machine, so the server cannot wipe its copies.
- An alert when a run fails, and another one when runs stop.
- A restore test that you repeat.
When rsync with cron is enough
- You need a plain, readable mirror on another machine, for example to switch to it quickly.
- The data changes rarely and is not sensitive, such as a static site whose source is also elsewhere.
- You want no extra software on the server. NeverWiped needs its agent, which runs as root (the agent).
Using both
They do different jobs: rsync for a live mirror you can switch to, NeverWiped for an encrypted history with consistent database dumps, in a place your server cannot wipe day to day.
Last reviewed: 6 November 2026. See also: all comparisons.