I recently lost a self-hosted server and want to learn enough Bash to automate backups. Ideally, I'd like to run them daily, copy only files that have changed, and eventually restore the data if something goes wrong. I know rsync can help with copying changed files, but I'm not sure how to schedule it safely or where to begin.
I'd also like to use Bash for small i3blocks scripts and other Linux automation. I tried writing a small dd-based script before and nearly damaged my computer, so I'd appreciate a beginner-friendly way to learn commands, pipes, conditions, grep, awk, man pages, and scheduling without just reading documentation all day. Should I build my own scripts, or start with an existing backup tool?
5 Answers
rsync is a reasonable tool for synchronizing files because it normally transfers only what has changed, but it is not automatically a complete backup system. If files are deleted or corrupted, a plain mirror may reproduce that problem. Snapshot-based filesystems and dedicated backup tools can preserve older versions. Once you understand the basics, you can use Bash to combine commands such as rsync with logging and scheduling rather than reimplementing backup logic yourself.
Learn Bash through small experiments instead of trying to memorize every command. Pick one task, read the relevant command’s manual with `man command`, try the examples in a disposable directory, and inspect the output. Useful beginner projects include renaming test files, counting lines, extracting a field from sample text, and creating a script that checks whether a directory exists. Then move on to variables, quoting, pipes, `if` statements, loops, `grep`, and `awk`. The Bash Guide from Linux Documentation Project and beginner Linux shell courses can provide a more structured path than reading random manual pages.
For your i3blocks goal, start with tiny scripts that do one thing, such as printing the date, checking memory usage, or showing disk space. Keep dangerous commands like `dd`, `rm`, and commands that write to devices out of your experiments until you understand exactly what they target. Use a temporary directory or virtual machine for practice, quote file paths, and add safety checks before changing real data.
For scheduling, look into a cron job or a systemd timer. Start with a manual command and make sure it works before automating it. A simple first project could back up one small test directory, print useful status messages, and write its output to a log. Once that is reliable, schedule it and add error handling. Also learn the 3-2-1 backup rule: keep three copies, on two different types of storage, with one copy somewhere else.
For data you genuinely care about, use a backup tool instead of making your first serious Bash project responsible for protecting everything. BorgBackup and restic are good examples: they support incremental backups, deduplication, integrity checks, encryption, and removing old backup versions. You can later write a small Bash script to run the tool and report whether it succeeded.
I’m still confused by things like `$?`, cron, and systemd timers, so I’ll start with a small manual script and learn those pieces separately instead of trying to automate everything at once.