Four programs for doing single-host-pair disk to disk backups

This software is owned by The university of California, Irvine, and is not distributed under any version of the GPL. GPL is a fine series of licenses, but the owners of the software need it to be distributed under these terms.

Table of contents:

What the programs have in common
Here's how they're different
Backup.local
Backup.remote
Backup.rsync
Backup.SRB

What these four programs have in common:

They're all available from here.
They're all written by the same author.
They're all bash scripts.
They're all intended for single-host-pair (or single host), disk to disk backups.
They're all intended to be run from cron.
They all do their thing as often as you schedule them from cron, including rotations.
They all have the same copyright.

Here's how they're different:

	First fullsave disk capacity efficiency	First fullsave network efficiency	First fullsave disk speed efficiency	First fullsave CPU efficiency	Subsequent disk capacity efficiency	Subsequent network efficiency	Subsequent disk speed efficiency	Subsequent CPU efficiency	Progress report	Retention
Backup.local	Good	No network load at all, unless using a network filesystem like NFS	Good	Very CPU intensive	Poor - no true incrementals	Poor - no true incremetals	Poor - all files are read	Very CPU intensive	Nice - from reblock	2 dailies, 2 weeklies, 2 monthlies
Backup.SRB	Good	Good	About one half to one third as disk bandwidth efficient as Backup.local, Backup.rsync or Backup.remote	Very CPU intensive	Poor - no true incrementals	Poor - no true incrementals	About one half to one third as disk bandwidth efficient as Backup.local, Backup.rsync or Backup.remote	Very CPU intensive	Nice - from reblock	2 dailies, 2 weeklies, 2 monthlies
Backup.rsync	About half as space efficient as Backup.local, Backup.SRB and Backup.remote	About half as network efficient as Backup.SRB and Backup.remote	Good	Very CPU efficient	Quite good - essentially all backups look like a fullsave, but only one copy of a given file is stored for a given host.	Very good - only new files and changed regions of modified files are transmitted	Pretty good - only changed files are read	Very CPU efficient	So so - from rsync	User-specified. "--num-to-keep 365" can keep approximately one year (modulo system crashes, etc.) if you run the script once a day.
Backup.remote	Good	Good	Good	Very CPU intensive	Poor - no true incrementals	Poor - no true incrementals	Poor - all files are read	Very CPU intensive	Nice - from reblock	2 dailies, 2 weeklies, 2 monthlies

Backup.local

Backup.local backs up data from a spot on a single host, to another spot on the same host - unless you use a network filesystem like NFS or SMB.
It'll by default, give you 2 dailies, 2 weeklies and 2 monthlies - all fullsaves.

Usage is currently like:

					seki-strombrg> ~/public_html/Backup.local --help
					Usage: /Dcs/seki/strombrg/public_html/Backup.local [--normal|--overwrite|--help]

					Normal mode will do a backup with rotation

					Overwrite mode will overwrite the last daily backup, without doing any rotation at all. It's for
					redoing a backup when a previous
					one fails.

Uses my reblock program if you run it on a tty, to give you a running progress report.

Backup.remote

Backup.remote backs up data from one host to another, using ssh.
It has command line options now. In the terminology of Backup.local, it is always in --normal mode.
It'll by default, give you 2 dailies, 2 weeklies and 2 monthlies - all fullsaves.
Uses my reblock program if you run it on a tty, to give you a running progress report.
To make Backup.remote not require an ssh password, you may want to read this document. You may also want to turn on root access via ssh in your system's sshd.conf, although since we're using tar archives you may be better off using a nonprivileged account.
It has pretty effective error recovery now. Not as good as Backup.rsync, but pretty good.
It compresses using zstd now.

Backup.rsync

Backup.rsync backs up data from one host to another, or from/to the same host, and can use rsh, ssh, native rsync, or just the plain POSIX file API, among other protocols.
There is no default number of backups to keep.
Storage and network I/O are vastly more efficient in this version, because only changed portions of changed files are transmitted and stored.

Usage is like:

$ ./Backup.rsync --help
below cmd output started 2015 Mon Dec 28 05:04:19 PM EST
Usage: ./Backup.rsync
	--srcdir /src/dir
	--dstdir /dest/dir
	--num-to-keep 365
	--verbose
	--rsync-opts rsopts
	--use-compression
above cmd output done 2015 Mon Dec 28 05:04:19 PM EST
dstromberg@connserv:~/src/home-svn/Backup-scripts/trunk x86_64-unknown-linux-gnu 14655

Progress output is generated by rsync itself, not by my reblock program.
To make Backup.rsync not require an ssh password, you may want to read this document. You may also want to turn on root access via ssh in your system's sshd.conf.

Backup.SRB and Restore.SRB

It'll by default, give you 2 dailies, 2 weeklies and 2 monthlies - all fullsaves.
Backs up using the SRB protocol from SDSC
Requires mtee and chunkup
This is mostly of historical interest today; SDSC no longer has such a service.

See also backshift, which is what the author of these scripts uses for backups today. It's slow, but frugal.