.\" vim: set ft=nroff .\"
.\" # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
.\" #
.\" #              C E D A R
.\" #          S O L U T I O N S       "Software done right."
.\" #           S O F T W A R E
.\" #
.\" # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
.\" #
.\" # Author   : Kenneth J. Pronovici <pronovic@ieee.org>
.\" # Language : nroff
.\" # Project  : Cedar Backup, release 3
.\" # Purpose  : Manpage for cback3 script
.\" #
.\" # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
.\"
.TH cback3 "1" "Aug 2019" "Cedar Backup 3" "Kenneth J. Pronovici"
.SH NAME
cback3 \- Local and remote backups to CD or DVD media or Amazon S3 storage
.SH SYNOPSIS
.B cback3
[\fIswitches\fR]
action(s)
.SH DESCRIPTION
.PP
The cback3 script provides the command\-line interface for Cedar Backup 3.
Cedar Backup 3 is a software package designed to manage system backups for a
pool of local and remote machines.  It understands how to back up filesystem
data as well as MySQL and PostgreSQL databases and Subversion repositories.  It
can also be easily extended to support other kinds of data sources.  
.PP
Cedar Backup 3 is focused around weekly backups to a single CD or DVD disc,
with the expectation that the disc will be changed or overwritten at the
beginning of each week.  If your hardware is new enough, Cedar Backup can
write multisession discs, allowing you to add incremental data to a disc on
a daily basis.
.PP
Alternately, Cedar Backup 3 can write your backups to the Amazon S3 cloud
rather than relying on physical media.
.SH BACKUP CONCEPTS
.PP
There are two kinds of machines in a Cedar Backup pool.  One machine (the
\fImaster\fR) has a CD or DVD writer on it and is where the backup is
written to disc.  The others (\fIclients\fR) collect data to be written to disc
by the master.  Collectively, the master and client machines in a pool are all
referred to as \fIpeer\fR machines.  There are four actions that take place as
part of the backup process: \fIcollect\fR, \fIstage\fR, \fIstore\fR and
\fIpurge\fR.  Both the master and the clients execute the collect and purge
actions, but only the master executes the stage and store actions.  The
configuration file \fI/etc/cback3.conf\fR controls the actions taken during
the collect, stage, store and purge actions.
.PP
Cedar Backup also supports the concept of \fImanaged clients\fR.  Managed
clients have their entire backup process managed by the master via a remote
shell.  The same actions are run as part of the backup process, but the master
controls when the actions are executed on the clients rather than the clients
controlling it for themselves.  This facility is intended for use in
environments where a scheduler like cron is not available.
.SH MIGRATING FROM VERSION 2 TO VERSION 3
.PP
The main difference between Cedar Backup version 2 and Cedar Backup version 3
is the targeted Python interpreter.  Cedar Backup version 2 was designed for
Python 2, while version 3 is a conversion of the original code to Python 3.
Other than that, both versions are functionally equivalent.  The configuration
format is unchanged, and you can mix\-and\-match masters and clients of different
versions in the same backup pool.  Both versions will be fully supported until
around the time of the Python 2 end\-of\-life in 2020, but you should plan to
migrate sooner than that if possible.
.PP
A major design goal for version 3 was to facilitate easy migration testing for
users, by making it possible to install version 3 on the same server where
version 2 was already in use.  A side effect of this design choice is that all
of the executables, configuration files, and logs changed names in version
3.  Where version 2 used \fIcback\fR, version 3 uses \fIcback3\fR:
\fIcback3.conf\fR instead of \fIcback.conf\fR, \fIcback3.log\fR instead of
\fIcback.log\fR, etc.
.PP
So, while migrating from version 2 to version 3 is relatively
straightforward, you will have to make some changes manually.  You will need to
create a new configuration file (or soft link to the old one), modify your cron
jobs to use the new executable name, etc.  You can migrate one server at a time
in your pool with no ill effects, or even incrementally migrate a single server
by using version 2 and version 3 on different days of the week or for different
parts of the backup.
.SH SWITCHES
.TP
\fB\-h\fR, \fB\-\-help\fR
Display usage/help listing.
.TP
\fB\-V\fR, \fB\-\-version\fR
Display version information.
.TP
\fB\-b\fR, \fB\-\-verbose\fR
Print verbose output to the screen as well writing to the logfile. When this
option is enabled, most information that would normally be written to the
logfile will also be written to the screen.
.TP
\fB\-q\fR, \fB\-\-quiet\fR
Run quietly (display no output to the screen).
.TP
\fB\-c\fR, \fB\-\-config\fR
Specify the path to an alternate configuration file.  The default configuration
file is \fI/etc/cback3.conf\fR.
.TP
\fB\-f\fR, \fB\-\-full\fR
Perform a full backup, regardless of configuration.  For the collect action,
this means that any existing information related to incremental backups will be
ignored and rewritten; for the store action, this means that a new disc will be
started.
.TP
\fB\-M\fR, \fB\-\-managed\fR
Include managed clients when executing actions.  If the action being executed
is listed as a managed action for a managed client, execute the action on that
client after executing the action locally.  
.TP
\fB\-N\fR, \fB\-\-managed-only\fR
Include only managed clients when executing actions.  If the action being
executed is listed as a managed action for a managed client, execute the action
on that client, but do not execute the action locally.
.TP
\fB\-l\fR, \fB\-\-logfile\fR
Specify the path to an alternate logfile.  The default logfile file is
\fI/var/log/cback3.log\fR.
.TP
\fB\-o\fR, \fB\-\-owner\fR
Specify the ownership of the logfile, in the form user:group.  The default
ownership is \fIroot:adm\fR, to match the Debian standard for most logfiles.  This
value will only be used when creating a new logfile.  If the logfile already
exists when the cback3 script is executed, it will retain its existing ownership
and mode.  Only user and group names may be used, not numeric uid and gid
values.
.TP
\fB\-m\fR, \fB\-\-mode\fR
Specify the permissions for the logfile, using the numeric mode as in chmod(1).
The default mode is \fI640\fR (\-rw\-r\-\-\-\-\-).  This value will only be used when
creating a new logfile.  If the logfile already exists when the cback3 script is
executed, it will retain its existing ownership and mode.
.TP
\fB\-O\fR, \fB\-\-output\fR
Record some sub-command output to the logfile. When this option is enabled, all
output from system commands will be logged. This might be useful for debugging
or just for reference.
.TP
\fB\-d\fR, \fB\-\-debug\fR
Write debugging information to the logfile. This option produces a high volume
of output, and would generally only be needed when debugging a problem. This
option implies the \-\-output option, as well.
.TP
\fB\-s\fR, \fB\-\-stack\fR
Dump a Python stack trace instead of swallowing exceptions.  This forces Cedar
Backup to dump the entire Python stack trace associated with an error, rather
than just propagating last message it received back up to the user interface.
Under some circumstances, this is useful information to include along with a
bug report.
.TP
\fB\-D\fR, \fB\-\-diagnostics\fR
Display runtime diagnostic information and then exit.  This diagnostic
information is often useful when filing a bug report.
.SH ACTIONS
.TP
\fBall\fR
Take all normal actions (collect, stage, store, purge), in that order.
.TP
\fBcollect\fR
Take the collect action, creating tarfiles for each directory specified in the
collect section of the configuration file.
.TP
\fBstage\fR
Take the stage action, copying tarfiles from each peer in the backup pool to
the daily staging directory, based on the stage section of the configuration
file.
.TP
\fBstore\fR
Take the store action, writing the daily staging directory to disc based on the
store section of the configuration file.
.TP
\fBpurge\fR
Take the purge action, removing old and outdated files as specified in the
purge section of the configuration file.
.TP
\fBrebuild\fR
The rebuild action attempts to rebuild "this week's" disc from any remaining
unpurged staging directories.  Typically, it is used to make a copy of a
backup, replace lost or damaged media, or to switch to new media mid-week for
some other reason.
.TP
\fBvalidate\fR
Ensure that configuration is valid, but take no other action.  Validation
checks that the configuration file can be found and can be parsed, and also
checks for typical configuration problems, such as directories that are not
writable or problems with the target SCSI device.
.SH RETURN VALUES
.PP
Cedar Backup returns 0 (zero) upon normal completion, and six other error
codes related to particular errors. 
.TP
\fB1\fR
The Python interpreter version is not supported.
.TP
\fB2\fR
Error processing command\-line arguments.
.TP
\fB3\fR
Error configuring logging.
.TP
\fB4\fR
Error parsing indicated configuration file.
.TP
\fB5\fR
Backup was interrupted with a CTRL\-C or similar.
.TP
\fB6\fR
Error executing specified backup actions.
.SH NOTES
.PP
The script is designed to run as root, since otherwise it's difficult to back
up system directories or write the CD or DVD device.  However, pains are taken
to switch to a backup user (specified in configuration) when appropriate.
.PP
To use the script, you must specify at least one action to take.  More than one
of the "collect", "stage", "store" or "purge" actions may be specified, in any
arbitrary order.  The "all", "rebuild" or "validate" actions may not be
combined with other actions.  If more than one action is specified, then
actions will be taken in a sensible order (generally collect, followed by
stage, followed by store, followed by purge).  
.PP
If you have configured any Cedar Backup extensions, then the actions associated
with those extensions may also be specified on the command line. If you specify
any other actions along with an extended action, the actions will be executed
in a sensible order per configuration. However, the "all" action never executes
extended actions.
.PP
Note that there is no facility for restoring backups.  It is assumed that the
user can deal with copying tarfiles off disc and using them to restore missing
files as needed.  The user manual provides detailed instructions in Appendix C.
.PP
Finally, you should be aware that backups to CD or DVD can probably be read
by any user which has permissions to mount the CD or DVD drive.  If you
intend to leave the backup disc in the drive at all times, you may want to
consider this when setting up device permissions on your machine.  You might
also want to investigate the encrypt extension.
.SH FILES
.TP
\fI/etc/cback3.conf\fR - Default configuration file
.TP
\fI/var/log/cback3.log\fR - Default log file
.SH URLS
.TP
The project homepage is: \fIhttps://github.com/pronovic/cedar\-backup3\fR
.SH BUGS
.PP
There probably are bugs in this code.  However, it is in active use for my own
backups, and I fix problems as I notice them.  If you find a bug, please report
it.  
.PP
If possible, give me the output from \-\-diagnostics, all of the error
messages that the script printed into its log, and also any stack\-traces
(exceptions) that Python printed.  It would be even better if you could tell me
how to reproduce the problem, for instance by sending me your configuration file.
.PP
Report bugs to <support@cedar\-solutions.com> or via GitHub issues
tracker.
.SH AUTHOR
Written and maintained by Kenneth J. Pronovici <pronovic@ieee.org> with contributions from others.
.SH COPYRIGHT
Copyright (c) 2004\-2020 Kenneth J. Pronovici.
.PP
This is free software; see the source for copying conditions.  There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.