2 Chapter 32. Multitape support in Amanda 2.2
3 Prev Part VI. Historical files Next
5 -------------------------------------------------------------------------------
7 Chapter 32. Multitape support in Amanda 2.2
18 XML-conversion;Updates
54 The goal of this enhancement is to make Amanda independent of the number of
55 tapes used per run or even per dump cycle. Specifically, I would like Amanda to
58 * output of amdump run goes to more than one tape
59 * a single dump file can straddle two tapes
60 * more than one amdump run can be done in a single day
61 * planner should not care how many runs per cycle occur
65 * multiple runs of amdump can go onto one tape (eg an append mode)
66 * any dump files from a previous run that are on the holding disk are written
67 to tape in this run (eg eliminate amflush)
68 * taper write to multiple tape drives simultaneously
76 Previously, planner marked time by the number of amdump runs, which it equated
77 with number of tapes, and number of days. In Amanda 2.2, Amanda keeps track of
78 the real passage of time, and doesn't generally care about the number of runs
79 or tapes between any two events.
80 While Amanda 2.2 doesn't care about spacing between runs, dump cycles are still
81 in terms of days, to make things easy to understand for the user. So, time
82 differences are rounded to the nearest 24 hours:
83 days_diff(A,B) = (<B> - <A> + 86400/2) / 86400
84 Where the times A and B are in seconds since the Unix epoch, and 86400 is the
85 number of seconds per day. This rounds a 2.49 day difference down to 2 days,
86 and a 2.5 day difference up to 3 days. No, Olafur, Unix time does not handle
87 leap seconds. Give me a break. :-)
91 The first thing planner does is calculate when each filesystem is due for a
92 full backup. This is trivial for normal backups:
93 full_is_due = days_diff(<time of last full>, <curtime>) >= dumpcycle
94 There is a complication for "skip-full" filesystems. Under 2.2, these will be
95 skipped on any runs that occur on the day the full is due, but we have to do
96 the right thing if multiple runs are done that day, and if no runs are done
97 that day (in which case we should be doing an incremental). Also, the time of
98 last full dump is a fiction maintained by the planner -- Amanda has no way to
99 tell whether the full backup was actually done or when it was done:
103 <time of last full> += dumpcycle;
104 if(days_diff(<time of last full>, <curtime>) == 0)
105 skip the filesystem on this run;
107 do an incremental dump of this filesystem;
114 The runtapes parameter tells planner how many tapes it should plan to use each
115 run. It multiplies this by the tape length to get the size available for the
116 run. (NOTE: later amend this size if appending to tapes, or if there are dumps
117 on the holding disk waiting to be flushed). Other than the size calculation,
118 planner doesn't really care how many tapes will be written to.
119 The fundamental problem with attempting to balance the schedule is that we no
120 longer know how many amdump runs will be done in a full cycle. The number may
121 change from cycle to cycle if there are extenuating circumstances.
122 So, planner must guess at how many runs will be done in one cycle, by looking
123 at the information for the last cycle, or, if this is the first cycle, assuming
124 one run for each day in the dump cycle.
128 When can a tape be overwritten, considering that it might have old dumps on it?
129 We want to be able to warn when full dumps are going to be overwritten, but
130 given the possibility of old files on the tape, how can we know when the tape
131 is no longer needed? I think we can get this when going through the info file,
132 considering each full dump and what tape it is on. Make sure we correctly
133 handle stale information.
140 taper must now handle writing to multiple tapes in one night, but choosing the
141 tapes from the tape rack is done one at a time as needed, re-applying the same
142 algorithm each time (see Amanda_Tape_Changer_Support).
146 As in earlier versions of Amanda, taper itself does not try to restrict writing
147 to the tape size given in the config file. It relied on planner having
148 correctly estimated backup sizes and limiting itself to what would fit on one
150 Now, taper needs to switch to a new tape when the current tape has filled up.
151 The tape is considered full when taper gets a write error. This will most
152 likely occur in the middle of writing a (potentially large) backup file,
153 perhaps even from a direct-to-tape socket, so there is no possibility of
154 starting the backup file over again on the next tape, it must start from where
155 it left off, rewriting the block that got the error on the next tape.
156 To insure correct operation, the file header of the continued file should
157 contain an indication that it is a continuation, and at what offset. amrestore
158 of course needs to be aware of this scheme and handle it correctly, perhaps by
159 double-buffering internally. XXX provide more alg details here, or just leave
160 it with the general idea?
164 We need to specify the sequence number of the tape in the run, in the tape
165 header file. The file header block specifies whether it is a continuation file
168 Tapelist File Changes
170 The lines in the tapelist file should contain the sequence number of the tape
171 in its run, as well as the amount of data written on the tape, and perhaps
172 whether or not the end of tape was reached.
176 Refer to http://www.amanda.org/docs/multitape.html for the current version of
178 -------------------------------------------------------------------------------
181 Chapter 31. What once was new Home Chapter 33. Thoughts about a Strategy API