The second iteration of my personal offline backup setup.

Originally developed as pendrive-stash, then extracted with git-subtree (hence the partially shared Git history) and converted to a different approach warranting it being a separate project.

Meant to be deployed to a pendrive or a similar device to keep a sparse backup of the most important files and directories.

Not intended to be generic or immediately configurable.

Instead intended to stay relatively simple and easy to modify with not much getting in the way. Preferably pure rsync with heavy use of the rsync filters to declare the files and directories intended for backup.

See: man rsync | less -p '^FILTER RULES'

Philosophy

The name backdown represents philosophy opposite to a typical backup.

The backdown backups aren't:

• complete; instead they are mostly sparse with rsync filters managing the logic
• incremental; each device holds only the last copied versions of files, the previous copy being replaced
• up to date; each device is just a dumb bulk storage that can be plugged on demand and the backup being refreshed with completely arbitrary frequency
• reliable; instead grab a handful of spare trash-grade pendrives and expect them to fail, just not all at once, and definitely not at the same time a proper backup fails too

One of my use cases is to carry one such backdown pendrive on me at all times, so I can always access my most important data. It might not be the most fresh copy, it might not contain everything, it might even happen to be broken, but most of the time it's a way to access some version of my data. And if it's broken, no data is truly lost as it's just a replica. It's meant as a complimentary tool to proper backups, BorgBackup being my personal recommendation.

Usage, design and conventions

Each device (or a "satellite") holding a backup is initialized with deploy.sh.

deploy.sh creates a clone of this repository with a custom ".git" directory. Instead of using the actual .git/ directory, the Git metadata directory is named .gitdata/ to avoid being auto-detected by Git when browsing the backed up files, which will more than likely include other Git repositories. This should avoid accidental actions on the main satellite repository. There is a local helper script ./git in each satellite to interact with this repository. If no arguments are passed, a new shell is spawned with $GIT_DIR pointed at this repository. deploy.sh sets core.worktree in .gitdata/config, see the git-config(1) manpage for the details. Lastly, deploy.sh adds the new satellite as a Git remote to the original repository, so it can be easily tracked when either of them gets updated.

Each top-level directory contains a script called pull.sh that will sync the backup against the live system.

Each such script should respect the variable $RSYNC_FLAGS that can be used to add custom rsync flags to the usual execution.

The top-level pull.sh script runs pull.sh from inside each directory in sequence.

Each pull.sh should contain little more than a call to rsync to copy over the files intended for this directory, possibly a few such calls.

Any filtering logic should be performed with the --filter option and merging the file called rsync-filter.txt and possibly additional rsync-*-filter.txt files loaded from it.