If you run a Linux server — whether it’s hosting a Nextcloud instance, a website, or critical business files — you already know that hardware fails, mistakes happen, and ransomware doesn’t send a warning email first. This guide walks through the exact commands and workflow for backing up data with rsync, cloning entire disks with dd, and compressing files with tar, so you can build a backup routine you can actually trust.

Table of Contents

1. Why Linux Backups Matter
2. Backing Up Files with rsync
3. Automating Backups with a Bash Script
4. Mirror Backups and Cleanup with –delete
5. Full Disk Backups with the dd Command
6. Compressing Files with tar
7. Modern Backup Tools Worth Knowing
8. Best Practices: The 3-2-1 Backup Rule
9. Conclusion

Why Linux Backups Matter

A server failure rarely announces itself in advance. Disks fail silently, admins delete the wrong directory, and ransomware can encrypt an entire filesystem within minutes. A well-known data protection framework built on three copies of your data, stored on two different media types, with one kept offsite, has become the baseline standard endorsed by major security agencies. Linux gives you everything you need to implement this yourself, for free, using tools that are already installed on almost every distribution.

Backing Up Files with rsync

rsync is the workhorse of Linux backups. It only transfers the parts of files that have changed, which makes repeated backups fast and bandwidth-efficient — ideal for syncing something like a Nextcloud data folder from a live server to a backup server.

Basic rsync Syntax

The general structure of every rsync command looks like this:

rsync [options] {source} {destination}

Preparing Source and Destination Folders

Before running any transfer, create matching folders on both machines. On the source server:

cd /mnt
mkdir nextcloud-server

On the backup server, create the destination and, importantly, set the correct owner on the mounted drive so the backup user actually has write access:

cd /mnt
mkdir backup-data && cd backup-data
mkdir nextcloud-bk
chown it -R nextcloud-bk

That chown step is easy to skip and one of the most common reasons rsync jobs silently fail with permission errors.

Local and Remote Backup Examples

Always test with --dry-run first — it simulates the transfer without touching any files, so you can review exactly what would happen:

rsync --dry-run -avz /mnt/nextcloud-server it@192.168.1.200:/mnt/backup/nexcloud-bk/

Once you’re confident the output looks correct, drop --dry-run to run it for real:

rsync -avz /mnt/nextcloud-server it@192.168.1.200:/mnt/backup/nexcloud-bk/

Here’s what each flag actually does:

Flag	Purpose
-a	Archive mode — preserves permissions, timestamps, symlinks, and ownership
-v	Verbose output, so you can see what’s being transferred
-z	Compresses data during transfer to save bandwidth
-X	Preserves extended file attributes
-A	Preserves the Access Control List (ACL)

For a single file over SSH with a live progress bar, use:

rsync -av --progress -e ssh myfile.pdf user@192.168.1.200:/mnt/remotedrive/

Automating Backups with a Bash Script

Manually typing backup commands is fine for a one-off transfer, but a real backup strategy needs to run unattended, every day, without you remembering to do it. A simple bash script solves this:

#!/bin/bash

DATE=$(date '+%F%T')
sudo rsync -avz myfile.pdf linuxserver@192.168.1.200:/mnt/remotedrive/$DATE'_BACK-UP'

Make it executable and run it:

chmod +x back-up.sh
./back-up.sh

You can format the $DATE variable however you like using standard date placeholders:

Placeholder	Meaning	Example
%Y	Year	2026
%m	Month (01–12)	08
%B	Full month name	August
%d	Day of month	03
%A	Full weekday name	Monday
%H:%M:%S	Hour:Minute:Second	14:32:07

Once this script works reliably, add it to cron (crontab -e) so it runs automatically every night without manual intervention.

Mirror Backups and Cleanup with –delete

By default, rsync only adds and updates files — it never removes anything from the destination, even if you deleted the original. If you want a true mirror, where the backup destination matches the source exactly, add the --delete flag:

rsync -a --delete -avz /mnt/nextcloud-server it@192.168.1.200:/mnt/backup/nexcloud-bk

Use this carefully. It’s powerful for keeping a clean, space-efficient mirror, but it also means an accidental deletion on the source will propagate to the backup on the next sync. For critical data, pair --delete with a separate, less frequent snapshot or offsite copy — never rely on a single mirrored backup alone.

Full Disk Backups with the dd Command

While rsync works at the file level, dd operates at the block level — it copies a disk or partition bit-for-bit, which is useful for cloning an entire system or creating a bootable image.

dd if=<input device> of=<output device> bs=<block size> count=<N> status=progress

Because dd writes directly to devices, a typo in the of= (output) argument can overwrite the wrong disk entirely. Always double-check device names with lsblk before running it, and reserve dd for full-disk cloning rather than everyday file backups — rsync is faster and safer for that job.

Compressing Files with tar

tar bundles multiple files into a single archive. On its own it doesn’t compress anything — it needs to be paired with a compression tool like gzip, bzip2, or xz.

Common tar Options

Option	Function
-c	Create an archive
-x	Extract an archive
-v	Verbose output
-p	Preserve permissions
--xattrs	Preserve extended attributes (ACLs, etc.)
-f	Specify the archive filename
-C	Change to a different directory before archiving
--gzip / --bzip2 / --xz	Compress the archive using the chosen algorithm

Archiving Without Compression

sudo tar --xattrs -cvpf etc.tar /etc

Check the size difference between the original folder and the plain archive — you’ll notice tar alone barely changes the total size, because it hasn’t compressed anything yet.

Compressing with gzip

Add the --gzip flag to shrink the archive significantly:

sudo tar --gzip --xattrs -cvpf etc.tar.gz /etc

In real-world testing, a folder like /etc can shrink from several megabytes down to a few hundred kilobytes once gzip compression is applied — a dramatic difference that matters when you’re transferring backups over a limited connection or paying for offsite storage by the gigabyte.

You can also compress a single file directly, though note that the original file is deleted once compressed:

gzip file.txt      # creates file.txt.gz, removes the original
gunzip file.txt.gz # decompresses it back

Modern Backup Tools Worth Knowing

rsync, dd, and tar cover the fundamentals, but if you’re backing up anything sensitive, it’s worth knowing what more specialized tools add on top:

• BorgBackup and restic — both add deduplication and encryption by default, meaning your offsite backups aren’t sitting in plain text if a cloud account is ever compromised.
• rclone — behaves like rsync but talks to cloud object storage (S3, Backblaze B2, and similar services), which is handy for the “offsite” leg of a backup strategy.

You don’t need to replace rsync with these tools — many admins use rsync for local, fast syncs and add an encrypted tool like restic for the offsite copy.

Best Practices: The 3-2-1 Backup Rule

Commands are only half the story — the strategy around them is what actually protects your data. The 3-2-1 approach means keeping three copies of your data: the original plus two extra copies, stored on two different types of media, with one copy kept off-site in a different datacenter, region, or provider entirely.

A few points worth building into your routine:

• Test your restores. A backup that has never been restored isn’t really a backup — it’s just a hope. Set a recurring reminder to actually restore a backup onto a throwaway server and confirm it works.
• Encrypt anything that leaves your network. Tools like restic and borg encrypt backups by default, while plain rsync does not, so add encryption yourself if you’re syncing to a third-party provider.
• Keep one copy immutable or offline. This protects your backup from being encrypted alongside your live data during a ransomware incident.
• Automate it. A backup strategy that depends on someone remembering to run a script manually will eventually fail. Cron plus a well-tested bash script closes that gap.

Conclusion

Backing up a Linux server doesn’t require expensive software — rsync, dd, and tar are already on your system and, combined correctly, cover file syncing, full disk cloning, and archive compression. The real work is building the habit around them: automate the job with a cron-scheduled script, mirror carefully with --delete, compress with tar --gzip to save space and bandwidth, and follow the 3-2-1 rule so no single failure — hardware, human error, or ransomware — can wipe out everything at once. Most importantly, restore what you’ve backed up at least once before you actually need to.