Fork: 0
tundra / tbku
Browse code
Changed example filenames to reflect datestamping of everything now.
Documented optional autodelete facility.
Minor edits.
master
1 parent 697aaf7 commit 8cbc79d3db00eee5ec2afe071af33f2bdefd5a95
@tundra tundra authored on 19 Mar 2008
Patch
Unified Split
Showing 1 changed file
View
116
■■■■■
 tbku.txt
``/bku/``). By default, the resulting tarball's name has a long
string of text that includes the machine name, system type, OS type,
date, *and* the so-called *set name*. The "set name" is nothing
more than the suffix of the name of the fileset used to produce the
tarball, in this case, ``homedirs``. Additionally, you'll also find
a log of the backup and "dot files" that tell you when the backup
began and when it ended. Here's part of what you might see if you
did an ``ls -al /bku``::
 
Mar 19 05:46 .mach.fake.org-FreeBSD-6.3-STABLE-i386-homedirs-begin
Mar 19 05:47 .mach.fake.org-FreeBSD-6.3-STABLE-i386-homedirs-end
Mar 19 05:46 mach.fake.org-FreeBSD-6.3-STABLE-i386-homedirs-20080319.tar.gz
Mar 19 05:46 mach.fake.org-FreeBSD-6.3-STABLE-i386-homedirs.log
tarball, in this case, ``homedirs``.
 
Additionally, you'll also find a log of the backup and "dot files"
that tell you when the backup began and when it ended. Here's part
of what you might see if you did an ``ls -a /bku``::
 
.mach.fake.org-FreeBSD-6.3-STABLE-i386-homedirs-20080319-begin
.mach.fake.org-FreeBSD-6.3-STABLE-i386-homedirs-20080319-end
mach.fake.org-FreeBSD-6.3-STABLE-i386-homedirs-20080319.tar.gz
mach.fake.org-FreeBSD-6.3-STABLE-i386-homedirs-20080319.log
 
The "dot files" don't actually contain any information, but their
date/time stamps (you can see this with ``ls -al /bku``) will tell
you when the backup began and ended.
 
The log file contains a list of all the files that actually
made it into the tarball. The log file also captures *the
errors* encountered during a backup. This means that ``tbku``
is generally pretty quiet during a backup run. It scribbles
any complaints it has into the log. So... you should check
your logs regularly to make sure everything is working as
expected.
 
You can create as many different filesets as you like (for as many
different kinds of backups as you need). So, for example, you may
have one for the files you want backed up daily, another for weekly
You may see ``tbku`` grumbling about having nothing to do. This
happens under one of several circumstances:
 
1) You ran ``tbku`` without arguments, but there are no
"auto" file sets defined.
 
2) You ran ``tbku`` with arguments, but no file sets with
"auto" filesets defined.
 
2) You ran ``tbku`` with arguments, but no filesets with
matching set names were found.
 
3) There are no file sets at all.
3) There are no filesets at all.
 
**Autodeletion Of Old Backups**
 
As shipped, ``tbku`` uniquely identifies each backup set based on
machine name, OS, CPU architecture, set name, and, most importantly,
date. If you've set it up to run as a cron job, over time you'll
accumulate lots of older copies of backups. That's because each new
day, the backup file name will change (since it include the date).
 
If you don't like this default behavior, change the ``TBKUDEL``
environment variable to be "YES". It must be *exactly* this string,
all in upper case. Anything else will cause ``tbku`` to *not*
autodelete old backups. This is intentional, to make it hard to
accidentally enable this feature.
 
Enabling this feature forces ``tbku`` to delete all older files
associated with the selected set name. This includes the start/stop
"dot" files, the log, and the backup tarball itself. In effect,
this option forces ``tbku`` to only keep the most recent backup of
each backup set.
 
*Use this option with caution!* If you only keep the most recent
copy of your backups in your backup directory, you may never be able
to get to changes made days, weeks, or months prior.
 
 
**IMAGING WITH tbku**
 
You can override the various ``tbku`` defaults by setting a
corresponding environment variable.
 
================= =============================== ======================
================= =============================== =========================
**Env. Variable** **Default Value** **Meaning**
----------------- ------------------------------- ----------------------
----------------- ------------------------------- -------------------------
TBKUDEL NO YES -> Delete old backups
TBKUDIR /bku Where to write backups
TBKUNAME $MACHINE-$OSTYPE-$OSREV-$HWTYPE Tarball base name
TBKUSETS $HOME/tbku Filesets found here
TBKUTAPE /dev/sa0 Tape device (or file)
================= =============================== ======================
================= =============================== =========================
 
 
Examples::
 
 
export TBKUSETS=/tbku # Looks for filesets in /tbku
 
export TBKUTAPE-/tmp/faketape # Tape backups actually written to *file*
 
export TBKUDEL="YES" # Autodelete old backups when starting a set
 
 
**OTHER**
 
``tbku`` was originally designed for use by experienced
systems administrators and users. As such, it does little
or no error checking. If you define backup or file set
or no error checking. If you define backup or fileset
directories that are non-existent, for instance, you will
get strange behavior. ``tbku`` *will* try to create the
backup directory you've specified if it does not already
exist, but this may not work if you're running as anything
information, see:
 
http://docutils.sourceforge.net/rst.html
 
``$Id: tbku.txt,v 1.107 2008/03/19 20:02:36 tundra Exp $``
``$Id: tbku.txt,v 1.108 2008/03/19 21:42:32 tundra Exp $``