{"slug": "everyday-rsync", "title": "Everyday rsync", "summary": "The article explains that rsync is a widely available file synchronization tool, commonly used for system backups, and highlights the author's preferred flags: `-av` for archive and verbose modes, `--delete` to keep remote folders in sync, and `--dry-run` to prevent mistakes. It notes that rsync dates back to 1996 and works on ancient or low-spec devices, requiring installation on both source and destination systems along with an SSH server for remote transfers. The post also provides installation commands for various Linux distributions and emphasizes using `--dry-run` to simulate operations before executing them.", "body_md": "Everyday rsync\nA blog post about using (and appreciating) rsync.\ntldr: my favorite rsync flags are -av. I use --delete when I'm trying to keep a remote folder in sync with the source. And --dry-run is critical for avoiding mistakes.\nI use rsync\nevery day for backing up systems.\nWhile rclone\nprovides some much-needed performance improvements and handling for offsite storage providers, rsync\nhas the advantage of being available virtually everywhere. This includes ancient systems (rsync\ndates back to 1996), as well as low-spec devices, where it can be difficult to realize advantages from powerful modern tools.\nMore than just a tool for copying files, rsync\nis a critical part of many backup routines. It's that scenario I'm addressing in this blog post: backing up a system's files to another location.\nThis is a companion blog post to a video I'm working up, which I'll link here when finished. :)\nInstalling rsync\nYou'll have to install the rsync\npackage on every system that'll use rsync\n- both the source and destination systems. It may already be included, rsync\nis a common enough dependency.\nAt the terminal, you can check if it's installed with which rsync\n. If you get a location back, congratulations! If the prompt returns no output, you'll have to install the rsync\npackage from your package manager.\nThe destination (system where you're sending the files) will require an openSSH server, in order to receive files from the source. If you're running systemd, you can check for a server with sudo systemctl status sshd\n. If you aren't running systemd you probably don't need a tutorial about rsync\n. :P\nInstallation on various distros\nDebian/Ubuntu/Mint/etc\nsudo apt update\nsudo apt install rsync\nsudo apt install openssh-server # for destination systems only\nFedora and derivatives\nsudo dnf install rsync\nsudo dnf install openssh-server # for destination systems only\nArch and derivatives\nsudo pacman -S rsync\nsudo pacman -S openssh # for destination systems only\nMaking sure SSH is installed\nYou almost certainly have SSH installed on your machine. If you manually removed it, you probably aren't using a tutorial for rsync\nin the first place.\nModern rsync\nsoftware uses SSH (Secure Shell) for sending files to a remote system, as well as receiving them. If you aren't sure, you can check that it's installed with which ssh\n.\nUsing rsync\nUsing rsync is straightforward:\nrsync [flags] [source] [destination]\nThe initial rsync\ninvokes the tool, but let's go over the other options.\nMy favorite everyday rsync flags\nDry run\nI'm putting this one first because you should get familiar with it: while you're learning rsync\nit's best to do actions as a --dry-run\n. This will simulate rsync\nwithout actually copying (or more importantly, deleting) any data. I've been rsync-ing before it was cool and I still --dry-run\nalmost every time I build a new rsync\nroutine. It's common sense.\nArchive\nI almost always run rsync\nwith -a\nfor backups: this is the archive flag, and consolidates -rlptgoD\ninto a single flag. This use of rsync\nwill preserve most attributes about your files, will be recursive (copy from subdirectories), and is much easier to remember than most of the other flags. Other than edge cases, it's what I use every day.\nVerbose\nI often run rsync\nin verbose mode (the -v\nflag). This provides me additional information about what rsync\nis doing. I don't always use it, particularly in scripted cases if I've built out my own logging and alerting. But even then, sometimes I pipe the results of -v\nto a text file to make a cheap log of sorts- at least during the testing phases anyway.\nDelete\nThis is scary, but not too scary. The idea is rsync\ncan delete files on the destination that don't exist on the source with the --delete\nflag. This keeps two folders in sync and keeps things tidy. I know I dislike going through my backups and finding old duplicates that are wasting space!\nThe thing about the --delete\nflag is that it can get you in trouble if you aren't careful with it. For example, one time I was pulling files (initiating rsync\nfrom the backup target instead of my everyday machine), and the remote system couldn't tell that one of my drives was unmounted. Because I was using --delete\n, guess what happened to my files on the backup machine?\nBecause of these sorts of gotchas, we generally recommend that beginners initiate rsync\nfrom the source machine and send files to the destination, what we call a push of files. It's a bit easier conceptually and I will say generally, it works just fine for me. There are edge cases where this is reversed, but by-and-large I prefer pushing when using the --delete\nflag.\nSetting an rsync source and destination\nThe source and destination format is pretty straightforward: give rsync\na path.\nFor a source example, let's say I have files in a \"cheese\" subdirectory inside my home\nfolder. My source might say ~/cheese\n. That will create a cheese\nsubdirectory inside the destination. If you don't want this subdirectory to be created (maybe it already exists), you'd put a trailing slash on the end of it: ~/cheese/\ninstead of ~/cheese\n.\nFor a destination, you can specify a local path, but this is probably an inefficient use of rsync\n: most of the time you'll be using a remote path over ssh: user@server\n, followed by a colon, then the path on the destination which will receive the files. And as mentioned above, you can invert this (using a remote path as the source), but generally (particularly for beginners) I do not recommend doing this, particularly not with the --delete\nflag. If you get things wrong you could delete your system.\nAs an aside: with SSH, you will have to authenticate against the remote system. By default this is going to be password authentication but that's lousy when you want to set up an automatic backup. I recommend using SSH keys for this, and I made a video years ago which describes this process pretty well. Someday I will upgrade the video to a blog post.\nSo finally an example\nOK, with all that out of the way, here's what an everyday rsync\nwould look like for me:\nFirst, testing it with --dry-run\n:\nrsync --dry-run -av --delete ~/cheese vkc@backup.lan:~/backups/\nThis looks good, the output shows me that it created every file inside my cheese\nsubdirectory over on the backup server.\nIt put them all in a new cheese\nsubdirectory as well- that may or may not be what you want. Maybe you have other backups in this folder and don't want to be deleting unintended files? That's why we dry-run!\nSo, a modification on this that protects other files in the backups\nsubdirectory would have me placing a slash after cheese\n, and then manually specifying a cheese\nsubdirectory in the destination, like this:\nrsync --dry-run -av --delete ~/cheese/ vkc@backup.lan:~/backups/cheese/\nNow the cheese stands alone- I'm only moving the files inside the cheese\nfolder, not the folder itself. And I'm specifying a dedicated location for the files to end up: the cheese\nsubdirectory inside the backups\ndirectory on my server. Beautiful.\nThat's the awesome thing about the --dry-run\nflag: it gives you the chance to see this stuff before you accidentally delete all of your backups. :)\nI can see it's not deleting files I don't intend, so I'm comfortable giving it a try. Simply remove the --dry-run\nflag and run it!\nrsync -av --delete ~/cheese/ vkc@backup.lan:~/backups/cheese/\nAn untested backup is just wishful thinking, so a quick SSH over to the server is in order to confirm that the files are there, and that everything is as I'm expecting it.\nPro tip: use tmux for lengthy rsync jobs\nI know most folks think of tmux\nas a terminal tiling tool, and yeah, that's how I often use it. But tmux\nhas a neat trick: you can detach from it, close the window, and go do something else.\nHere's the scenario: I'm SSH'd into a server and preparing to run a lengthy rsync\njob (or rclone\nor any other lengthy file transfer really). But I really want to go home for the day and want to shut off my computer.\nThis is where tmux\nis a viking. You might need to install the package for your system, but you can run tmux\n, and then start your long rsync run there. Then detach from tmux\nwith <ctrl-b> followed by the d key.\nNow, as long as the computer is running (in this scenario, a server running an rsync\ntask), I can disconnect from the server, and go live my life while the long process runs. I can check on it again by SSH-ing into the server and then run tmux a\nto re-attach to the session.\nBut Veronica... rsync is slow\nYup. It is. It's a very old-school way to do this. But I'm going to argue that's a good thing in a lot of cases.\nIf I'm running a virtual server and only have two cores available to the VM, rsync\ndoesn't have a significant performance difference from rclone\n, but it is immediately recognizable by other admins. I cannot stress for you how important familiarity and ubiquity are in a professional setting. I will concede that rclone\nis gaining popularity and might become an acceptable alternative, but it's still not as commonplace as rsync\nin scripts or other utilities.\nMy day-to-day desktop systems might use other tools for big backups, but everyday scheduled backups, like copying my video drafting directory to my NAS, benefit from rsync\nand it's ancient, single-threaded nature: I don't want to devote significant resources to the backup process while I'm working on editing a video. In this case, slow and non-performant is a feature, not a bug: rsync\nmight take its time but it's not going to interfere with my work, either. When rclone\nis running full bore I can feel the computer throttle up- you don't want that during a recording session.\nSo there's nuance. Such is life. Anyone telling you rsync\nis dead is being dishonest, or naive. Use what works for you!", "url": "https://wpnews.pro/news/everyday-rsync", "canonical_source": "https://veronicaexplains.net/everyday-rsync/", "published_at": "2025-10-01 16:03:25+00:00", "updated_at": "2026-05-23 20:09:32.996345+00:00", "lang": "en", "topics": ["open-source", "developer-tools", "data"], "entities": ["rsync", "rclone"], "alternates": {"html": "https://wpnews.pro/news/everyday-rsync", "markdown": "https://wpnews.pro/news/everyday-rsync.md", "text": "https://wpnews.pro/news/everyday-rsync.txt", "jsonld": "https://wpnews.pro/news/everyday-rsync.jsonld"}}