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
|
.TH AFVERIFY 8 "1998 February 9" "Debian Project"
.SH NAME
afverify \- verify of a previous backup
.SH SYNOPSIS
.B afverify
[ -c <configuration-file> ]
[ -<past-run-no>[.<past-backup-no>] ]
[ -h <backuphosts> ] [ -P <backup-ports> ]
[ -C <root-directory> ] [ -S <cartridge-set> ]
[ -I <indexfile-part> ] [ -V <var-directory> ]
[ -k <encryption-key-file> ]
[ -z <compress-cmd> <uncompress-cmd> ]
.SH DESCRIPTION
Without any arguments, this program runs a verify over the
previously written backup. This may either be a full or an
incremental backup, only the contents of the very previous
run are used. All found differences are reported.
Though it is not considered to make too much sense, it is
also provided, that files and directories saved during a run
before the previous one can be checked. This can be done
supplying the <past-backup-specifier>. If this is a simple
number, it counts back from the previous full or incremental
backup of the same total backup number (this number is increased
each run of the full_backup-command, not by subsequent
incremental backups). -1 means, that the backup before the
previous one is checked and so on. If the contents of a previous
total backup run should be checked, the following form
may be used: -<previous-run>.<previous-total-backup>, where
<previous-total-backup> counts back from the actual total backup
number and <previous-run> counts back from the last backup
(incremental or full) run among the previous total. previous-run
may be 0 here. E.g. verify -0.1 checks the files saved during
the last run of the previous total backup
.PP
.TP
.B -C <rootdir>
change to the given root-directory before verifying
files instead of the one specified in the client
side configuration file.
.TP
.B -c <configfile>
Use the given file for configuration information
.TP
.B -h <hostnames>
Use the given list of hosts as backup servers. This
list is used only, if no hostname information can
be found as associated with the actual filesystem
entry, that should be verified. The first host in
this list is the default server, if no hostname
information at all can be found. The hostnames in
this list can be separated by whitespace and/or
commas
.TP
.B -I <idx-prefix>
The first part of the filename, the names of the
stored files and directories are written to. The
current total backup number is appended (that
increments each start of a full backup). If these
files undergo compression, .z is appended
.TP
.B -k <file>
Use the contents of the given file as encryption
key for authenticating to the server
.TP
.B -P <portnos>
The list of port numbers for the backup servers
either configured in the parameter file or supplied
with the -h option. This list is used only, if no
port number information can be found as associated
with the actual filesystem entry, that should be
verified. The port numbers supplied here are asso-
ciated with the backup server names by position.
The port numbers in this list can be separated by
whitespace and/or commas
.TP
.B -V <var-dir>
The directory, where varying files are put
.TP
.B -z <zipcmd> <unzipcmd>
The commands to use for compress and uncompress. If
a command comprises of several words, it must be
put in quotes
.PP
In my opinion a verify makes only sense immediately following
an incremental or full backup with the purpose to check, whether
the files and directories did not get corrupt on the storage
media. If you want to do this (via cron or however), keep in
mind, that the verify takes at least the same time as the
backup itself. If you have a huge amount of data to save, the
additional verify might consume a lot of time.
.SH FILES
.IP @clientlibdir@/@clientconf@
Client configuration file
.IP @clientlogdir@
The directory for logging the client backups
.IP @clientvardir@
Some internal state information of the client backups.
.SH SEE ALSO
afclientconfig(8), xafclientconfig(8), full_backup(8),
incr_backup(8), afverify(8), afrestore(8), print_errors(8),
afclient.conf(8), afserver.conf(8),
tar(1)
.SH AUTHOR
.B afbackup
was written by Albert Fluegel (af@muc.de). This manpage was
extracted from the text docs by Christian Meder
(meder@isr.uni-stuttgart.de).
|
