+
+ ```sh
+ bup index /etc
+ bup save -n local-etc /etc
+ ```
+
+ - Look how little extra space your second backup used (on top of the first):
+
+ ```sh
+ du -s ~/.bup
+ ```
+
+ - Get a list of your previous backups:
+
+ ```sh
+ bup ls local-etc
+ ```
+
+ - Restore your first backup again:
+
+ ```sh
+ bup restore -C ./dest-2 local-etc/2013-11-23-11195/etc
+ ```
+
+ - Make a backup to a remote server which must already have the 'bup' command
+ somewhere in its PATH (see /etc/profile, etc/environment, ~/.profile, or
+ ~/.bashrc), and be accessible via ssh.
+ Make sure to replace SERVERNAME with the actual hostname of your server:
+
+ ```sh
+ bup init -r SERVERNAME:path/to/remote-bup-dir
+ bup index /etc
+ bup save -r SERVERNAME:path/to/remote-bup-dir -n local-etc /etc
+ ```
+
+ - Make a remote backup to ~/.bup on SERVER:
+
+ ```sh
+ bup index /etc
+ bup save -r SERVER: -n local-etc /etc
+ ```
+
+ - See what saves are available in ~/.bup on SERVER:
+
+ ```sh
+ bup ls -r SERVER:
+ ```
+
+ - Restore the remote backup to ./dest:
+
+ ```sh
+ bup restore -r SERVER: -C ./dest local-etc/latest/etc
+ ls -l dest/etc
+ ```
+
+ - Defend your backups from death rays (OK fine, more likely from the
+ occasional bad disk block). This writes parity information
+ (currently via par2) for all of the existing data so that bup may
+ be able to recover from some amount of repository corruption:
+
+ ```sh
+ bup fsck -g
+ ```
+
+ - Use split/join instead of index/save/restore. Try making a local
+ backup using tar:
+
+ ```sh
+ tar -cvf - /etc | bup split -n local-etc -vv
+ ```