|
Hi there, you managed to find the sitback homepage..
Sitback is actual just another tar/gzip interface. It evolved from
a bash-script i wrote to handle automated backup's on linux fileservers.
The script worked ok, but it soon proved difficult and tiresome to make local
modifications to the script to handle various problems or differences.
I began searching the web to find a suitable backup tool, and came up with
some candidates. But they all did not do exactly what i wanted, or they
were just too big and filled with features that i did not need.
One of the things i needed was a way of reporting the result of a backup to
office peoples. (You know.. Press the button and wait for Windows to start,
call support if anything unexpected happens..), so a printed report, readable by
non-nerds was required..
In the end, i desided that a homebrew system was required and began to put this little
tool together..
Tar has been, and is, one of the best archiving utility's around, at least on
small scale systems (wich is what i work on), so i saw no reason to abandon tar.
It is known to be stable and produce error-free archives, why should i then
start all over and invent another file-storage protocol ??.
Sitback works like a kind of super-intelligent script. Just
tell it what you want to backup and where to put it.. Sitback takes care of the
rest, including finding the tools needed, wich compression to use (if you want that),
how to handle the archive device, etc. etc.
Sitback will take care of checking the files, verify the archive and maintain
a little database, so that you, very quickly, can find out on wich tape a certain
file is located, without using the tape..
Sitback can run a single backup operation, or you can ask it to fork into the
background and do automated backups (this is where the printed report is nice to
have, 'no report... or... report say's ERROR... then call for support').
Sitback has a graphic (more or less) interface, when you run sitback directly from
the shell. Currently based on ncurses, but a better version, running on X will
be implemented later.. (Sitback will find out if X is started and if not, use the
ncurses interface).
If you run Sitback as a daemon, making scheduled backup's, no interface is available,
but the logfile contains all important messages.
So.. What is missing..
Sitback is not a network or distributed systems backup tool, although
you may very well use nfs or smb shares mounted on your local VFS.
(all file locations or devices that tar can see is usable)..
Sitback does not know how to operate advanced backup hardware, such as
multiple tape stations, cdrom or dvd writers (maybe sometime in the future).
Why bother..
Sitback saves you the time you would spend writing and
tweaking a shell script. It gives you a simple way of doing automated backups,
without having to know all details about you tape-drive, tar, mt etc. etc.
It helps you to keep track when you have different archives.
It gives you the good performance of tar along with the well known stability,
wich ensures that you do not get invalid archives...
You dont depend on having sitback available to restore an archive. You can
bring the archive somewhere else and extract the files. Or you can extract
the files on a newly installed system, f.ex. after a complete crash...
No need to install extra tools to get access to your emergency backup. Just Tar.
Sitback can help you doing trivial archiving on your local system, f.ex. daily
or weekly backup to f.ex. zip disk's.
In other words, consider sitback as a super-smart tar that takes care of
things you else would have to code yourself.
| |