git.gag.com Git - debian/amanda/blob - docs/multitape.txt

   1
   2 Chapter 32. Multitape support in Amanda 2.2
   3 Prev  Part VI. Historical files        Next
   4
   5 -------------------------------------------------------------------------------
   6
   7 Chapter 32. Multitape support in Amanda 2.2
   8
   9
  10 James da Silva
  11
  12 Original text
  13 AMANDA Core Team
  14 <jds@amanda.org>
  15
  16 Stefan G. Weichinger
  17
  18 XML-conversion;Updates
  19 AMANDA Core Team
  20 <sgw@amanda.org>
  21 Draft 1 - jds 3/29/94
  22 Table of Contents
  23
  24
  25   Introduction
  26
  27   New_Planner_Algorithm
  28
  29
  30         Time
  31
  32         Full_Backups
  33
  34         Schedule_Balancing
  35
  36         Overwrite_Detection
  37
  38
  39   Taper_Algorithm
  40
  41
  42         Choosing_a_tape
  43
  44         End_of_tape_handling
  45
  46         Tape_Format_Changes
  47
  48         Tapelist_File_Changes
  49
  50
  51
  52 Note
  53
  54 Refer to http://www.amanda.org/docs/multitape.html for the current version of
  55 this document.
  56
  57  Introduction
  58
  59 The goal of this enhancement is to make Amanda independent of the number of
  60 tapes used per run or even per dump cycle. Specifically, I would like Amanda to
  61 handle the following:
  62
  63 * output of amdump run goes to more than one tape
  64 * a single dump file can straddle two tapes
  65 * more than one amdump run can be done in a single day
  66 * planner should not care how many runs per cycle occur
  67
  68 And later:
  69
  70 * multiple runs of amdump can go onto one tape (eg an append mode)
  71 * any dump files from a previous run that are on the holding disk are written
  72   to tape in this run (eg eliminate amflush)
  73 * taper write to multiple tape drives simultaneously
  74
  75
  76  New Planner Algorithm
  77
  78
  79  Time
  80
  81 Previously, planner marked time by the number of amdump runs, which it equated
  82 with number of tapes, and number of days. In Amanda 2.2, Amanda keeps track of
  83 the real passage of time, and doesn't generally care about the number of runs
  84 or tapes between any two events.
  85 While Amanda 2.2 doesn't care about spacing between runs, dump cycles are still
  86 in terms of days, to make things easy to understand for the user. So, time
  87 differences are rounded to the nearest 24 hours:
  88 days_diff(A,B) = (<B> - <A> + 86400/2) / 86400
  89 Where the times A and B are in seconds since the Unix epoch, and 86400 is the
  90 number of seconds per day. This rounds a 2.49 day difference down to 2 days,
  91 and a 2.5 day difference up to 3 days. No, Olafur, Unix time does not handle
  92 leap seconds. Give me a break. :-)
  93
  94  Full Backups
  95
  96 The first thing planner does is calculate when each filesystem is due for a
  97 full backup. This is trivial for normal backups:
  98 full_is_due = days_diff(<time of last full>, <curtime>) >= dumpcycle
  99 There is a complication for "skip-full" filesystems. Under 2.2, these will be
 100 skipped on any runs that occur on the day the full is due, but we have to do
 101 the right thing if multiple runs are done that day, and if no runs are done
 102 that day (in which case we should be doing an incremental). Also, the time of
 103 last full dump is a fiction maintained by the planner -- Amanda has no way to
 104 tell whether the full backup was actually done or when it was done:
 105
 106         if(skip-full) {
 107                 if(full_is_due)
 108                         <time of last full> += dumpcycle;
 109                 if(days_diff(<time of last full>, <curtime>) == 0)
 110                         skip the filesystem on this run;
 111                 else
 112                         do an incremental dump of this filesystem;
 113         }
 114
 115
 116
 117  Schedule Balancing
 118
 119 The runtapes parameter tells planner how many tapes it should plan to use each
 120 run. It multiplies this by the tape length to get the size available for the
 121 run. (NOTE: later amend this size if appending to tapes, or if there are dumps
 122 on the holding disk waiting to be flushed). Other than the size calculation,
 123 planner doesn't really care how many tapes will be written to.
 124 The fundamental problem with attempting to balance the schedule is that we no
 125 longer know how many amdump runs will be done in a full cycle. The number may
 126 change from cycle to cycle if there are extenuating circumstances.
 127 So, planner must guess at how many runs will be done in one cycle, by looking
 128 at the information for the last cycle, or, if this is the first cycle, assuming
 129 one run for each day in the dump cycle.
 130
 131  Overwrite Detection
 132
 133 When can a tape be overwritten, considering that it might have old dumps on it?
 134 We want to be able to warn when full dumps are going to be overwritten, but
 135 given the possibility of old files on the tape, how can we know when the tape
 136 is no longer needed? I think we can get this when going through the info file,
 137 considering each full dump and what tape it is on. Make sure we correctly
 138 handle stale information.
 139
 140  Taper Algorithm
 141
 142
 143  Choosing a tape
 144
 145 taper must now handle writing to multiple tapes in one night, but choosing the
 146 tapes from the tape rack is done one at a time as needed, re-applying the same
 147 algorithm each time (see Amanda_Tape_Changer_Support).
 148
 149  End of tape handling
 150
 151 As in earlier versions of Amanda, taper itself does not try to restrict writing
 152 to the tape size given in the config file. It relied on planner having
 153 correctly estimated backup sizes and limiting itself to what would fit on one
 154 tape.
 155 Now, taper needs to switch to a new tape when the current tape has filled up.
 156 The tape is considered full when taper gets a write error. This will most
 157 likely occur in the middle of writing a (potentially large) backup file,
 158 perhaps even from a direct-to-tape socket, so there is no possibility of
 159 starting the backup file over again on the next tape, it must start from where
 160 it left off, rewriting the block that got the error on the next tape.
 161 To insure correct operation, the file header of the continued file should
 162 contain an indication that it is a continuation, and at what offset. amrestore
 163 of course needs to be aware of this scheme and handle it correctly, perhaps by
 164 double-buffering internally. XXX provide more alg details here, or just leave
 165 it with the general idea?
 166
 167  Tape Format Changes
 168
 169 We need to specify the sequence number of the tape in the run, in the tape
 170 header file. The file header block specifies whether it is a continuation file
 171 or not.
 172
 173  Tapelist File Changes
 174
 175 The lines in the tapelist file should contain the sequence number of the tape
 176 in its run, as well as the amount of data written on the tape, and perhaps
 177 whether or not the end of tape was reached.
 178 -------------------------------------------------------------------------------
 179
 180 Prev                            Up                                        Next
 181 Chapter 31. What once was new  Home  Chapter 33. Thoughts about a Strategy API
 182