File: README

package info (click to toggle)
afbackup 3.1beta1-1
  • links: PTS
  • area: main
  • in suites: slink
  • size: 1,500 kB
  • ctags: 1,685
  • sloc: ansic: 22,406; csh: 3,597; tcl: 964; sh: 403; makefile: 200
file content (208 lines) | stat: -rw-r--r-- 6,507 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208


AF's backup system
------------------

This is a client-server backup system offering several
workstations a centralized backup to special backup
servers. The backup on the clients can be started auto-
matically using cron-jobs on the clients, but the more
intelligent solution is to start it remotely from a central
administrative host. To be independent of tricks like
rsh, rcp and so on, that are in fact security holes,
this remote start option is internally realized. This
is done because normally the backup has to be run with
root authorization, otherwise files that are read
protected by users could not be saved. Any streaming
device can be used for writing the data to it. The only
thing it must be able to is to distinguish between
several files on tape so that it can be positioned directly.
Writing backups is normally done sequentially: The
next writing to tape goes to the end of the previous
write no matter where you have restored from in the
meantime. There is a special possibility for the
administrator to change the next writing position,
but this should be done only in emergency cases (See:
PROGRAMS, "cartis").
A more thorough introduction can be found in the file
INTRO, all changes in comparison with earlier releases
are listed in the file Changes.

The server side has been tested on Linux, AIX, IRIX, FreeBSD,
Digital Unix (OSF1) and HP-UX, the client side on Linux, AIX,
IRIX, Solaris, HP-UX, FreeBSD and Digital Unix (OSF1).


DISCLAIMER
----------

These programs come without any warranty. Everybody using
this software does so on his or her very own risk. The C-
code has nonetheless been running over a year without
problems and should have no bugs - at least if there are, they
didn't hurt any backup or restore. The installation and
configuration scripts have been added recently and might have
bugs (but some testing has been done of course).


PLEASE
------

Can someone (-: PLEASE :-) do me the favour and:

- tell me, if she or he finds unusual, strange or simply
  wrong English in my texts.


FEATURES
--------

- Client-/Server-System

- Authentication of the client is performed before it can
  take over control (see INSTALL) -> security

- Several servers for one client can be configured for each
  client, actual server is chosen by availability

- Remote start option -> centralized administration

- Access restriction for the streamer device -> security

- Client-side per-file compression -> reliability. If the
  files and directories were first packed and then compressed,
  a single faulty bit in the compressed stream would make the
  rest of the backup unaccessible for restore

- Data stream is written to tape in pieces -> fast finding
  of files during restore

- Tape position logging for each file -> fast finding
  of files during restore

- Tape capacity is fully used

- Full / incremental backups and verify

- Raw partitions can be saved

- Ordinary users can run the restore for their own files
  and directories, but only for these


WHAT YOU NEED
-------------

GNU make. Others may not work, but all should (thanks to
autoconfig)

A streaming device. This can be either a cartridge handling
system or a simple drive. In the latter case you might want
to maintain several cartridges nonetheless. Just buy them
and write numbers to them starting with 1. The backup server
will supply you with email when a tape must be put in and
which it should be. The number of cartridges is configurable.

A compression program on the client side, if you want to use
the compression feature, which is not mandatory.

Some space for the logfiles. All the names of the saved files
and directories are written to log files, which could grow to
a notable size if a lot of files are saved.


INSTALLATION
------------

See: INSTALL


UPGRADE
-------

See: UPGRADE


CONFIGURATION
-------------

See: CONFIG, INTRO and HOWTO.FAQ.DO-DONT


BEFORE YOU START
----------------

... Your first backup! Put your tape cartridge number 1 into
the drive or make your cartridge handling system do so. If
you don't want this or can't persuade your cartridge handler
to do so, find out the number of the cartridge which is
actually inside the drive. Then enter the following commands
on the backup server (the host, the drive is connected to)
replacing <num> with the real cartridge number:

$BASEDIR/server/bin/cartis <num>
$BASEDIR/server/bin/cartis -i <num> 1

The first command tells the server the number of the cartridge,
that actually is in the drive. The second one says: Write the
next backup to the named cartridge, file 1 (the data stream is
written in pieces==files to tape). See: PROGRAMS. $BASEDIR
always stands for your chosen installation directory.


WHAT CAN BE STARTED: PROGRAMS
-----------------------------

See: PROGRAMS


LIMITATIONS AND KNOWN BUGS
--------------------------

No bugs known. No multi-stream-backups implemented.

Please report bugs and suggestions for new features to:

af@muc.de

If you have problems, please add the last lines of the file(s)
.../client/var/backup.log and .../server/var/backup.log to
your posting, if present. Please add everything, too, what you
think might be important.

If you want to be informed about important changes or bugfixes,
send an email to af@muc.de with the subject line containing:
 subscribe backup-news


TO DO
-----

Reduce the limitations.
Port the client side to other platforms.


THANKS TO
---------

 (in chronolocigal order)
- The people at "Zentrum fuer Neuroinformatik" for being so
  kind letting me put this into the PD.
- Rick Macdougall at Axess Communications for reviewing my
  bad English. (A lot of text has been added up to now, he
  had no chance to review it - so it's my fault, if there is
  a lot of nonsense)
- Lars Koeller at the University of Bielefeld, Germany, for
  doing the FreeBSD-port and giving me some important hints.
- Christian Meder at the University of Stuttgart, Germany,
  for bug reports, fixes, making the whole package autoconfig-
  -urable and Debian-ready, extracting the man-pages and a lot
  more
- Ivan N. Kokshaysky at the Moscow State University for making
  afbackup libc-6 (ie. glibc) - ready
- Katharina Hoffman at Infomedia GmbH for doing a lot of tests
- GianPiero Puccioni (gip@ino.it) at "Istituto Nazionale di Ottica"
  in Firenze for doing a lot of testing and problem determination,
  furthermore contributing the mtx.c program for using DAT
  autochangers, all on HP-UX.
- Tuomo Soini (tis@bleve.icon.fi) for 'feature' fixing