git.gag.com Git - debian/amanda/blob - docs/MULTITAPE

   1
   2 MULTITAPE SUPPORT IN AMANDA 2.2
   3
   4 Draft 1 - jds 3/29/94
   5
   6 1. INTRODUCTION
   7
   8 The goal of this enhancement is to make Amanda independent of the number of
   9 tapes used per run or even per dump cycle.  Specifically, I would like
  10 amanda to handle the following:
  11
  12         - output of amdump run goes to more than one tape
  13         - a single dump file can straddle two tapes
  14         - more than one amdump run can be done in a single day
  15         - planner should not care how many runs per cycle occur
  16
  17 And later:
  18
  19         - multiple runs of amdump can go onto one tape (eg an append mode)
  20         - any dump files from a previous run that are on the holding disk
  21           are written to tape in this run (eg eliminate amflush)
  22         - taper write to multiple tape drives simultaneously
  23
  24
  25 2. NEW PLANNER ALGORITHM
  26
  27 2.1 TIME
  28
  29 Previously, planner marked time by the number of amdump runs, which it
  30 equated with number of tapes, and number of days.  In Amanda 2.2, amanda
  31 keeps track of the real passage of time, and doesn't generally care about
  32 the number of runs or tapes between any two events.
  33
  34 While Amanda 2.2 doesn't care about spacing between runs, dump cycles are
  35 still in terms of days, to make things easy to understand for the user.
  36 So, time differences are rounded to the nearest 24 hours:
  37
  38         days_diff(A,B) = (<B> - <A> + 86400/2) / 86400
  39
  40 Where the times A and B are in seconds since the Unix epoch, and 86400 is
  41 the number of seconds per day.  This rounds a 2.49 day difference down to 2
  42 days, and a 2.5 day difference up to 3 days.  No, Olafur, Unix time does
  43 not handle leap seconds.  Give me a break. :-)
  44
  45 2.2 FULL BACKUPS
  46
  47 The first thing planner does is calculate when each filesystem is due for a
  48 full backup.  This is trivial for normal backups:
  49
  50         full_is_due = days_diff(<time of last full>, <curtime>) >= dumpcycle
  51
  52 There is a complication for "skip-full" filesystems.  Under 2.2, these will
  53 be skipped on any runs that occur on the day the full is due, but we have
  54 to do the right thing if multiple runs are done that day, and if no runs
  55 are done that day (in which case we should be doing an incremental).  Also,
  56 the time of last full dump is a fiction maintained by the planner -- Amanda
  57 has no way to tell whether the full backup was actually done or when it was
  58 done:
  59
  60         if(skip-full) {
  61                 if(full_is_due)
  62                         <time of last full> += dumpcycle;
  63                 if(days_diff(<time of last full>, <curtime>) == 0)
  64                         skip the filesystem on this run;
  65                 else
  66                         do an incremental dump of this filesystem;
  67         }
  68
  69
  70 2.3 SCHEDULE BALANCING
  71
  72 The "runtapes" parameter tells planner how many tapes it should plan to use
  73 each run.  It multiplies this by the tape length to get the size available
  74 for the run.  (NOTE: later amend this size if appending to tapes, or if
  75 there are dumps on the holding disk waiting to be flushed).  Other than the
  76 size calculation, planner doesn't really care how many tapes will be
  77 written to.
  78
  79 The fundamental problem with attempting to balance the schedule is that we
  80 no longer know how many amdump runs will be done in a full cycle.  The
  81 number may change from cycle to cycle if there are extenuating
  82 circumstances.
  83
  84 So, planner must guess at how many runs will be done in one cycle, by
  85 looking at the information for the last cycle, or, if this is the first
  86 cycle, assuming one run for each day in the dump cycle.
  87
  88 2.4 OVERWRITE DETECTION
  89
  90 When can a tape be overwritten, considering that it might have old dumps on
  91 it?  We want to be able to warn when full dumps are going to be
  92 overwritten, but given the possibility of old files on the tape, how can we
  93 know when the tape is no longer needed?  I think we can get this when going
  94 through the info file, considering each full dump and what tape it is on.
  95 Make sure we correctly handle stale information.
  96
  97
  98 3. TAPER ALGORITHM
  99
 100 3.1 CHOOSING A TAPE
 101
 102 Taper must now handle writing to multiple tapes in one night, but choosing
 103 the tapes from the tape rack is done one at a time as needed, re-applying
 104 the same algorithm each time (see TAPE.CHANGERS).
 105
 106 3.2 END OF TAPE HANDLING
 107
 108 As in earlier versions of Amanda, Taper itself does not try to restrict
 109 writing to the tape size given in the config file.  It relied on planner
 110 having correctly estimated backup sizes and limiting itself to what would
 111 fit on one tape.
 112
 113 Now, Taper needs to switch to a new tape when the current tape has filled
 114 up.  The tape is considered full when taper gets a write error.  This will
 115 most likely occur in the middle of writing a (potentially large) backup
 116 file, perhaps even from a direct-to-tape socket, so there is no possibility
 117 of starting the backup file over again on the next tape, it must start from
 118 where it left off, rewriting the block that got the error on the next tape.
 119
 120 To insure correct operation, the file header of the continued file should
 121 contain an indication that it is a continuation, and at what offset.
 122 amrestore of course needs to be aware of this scheme and handle it
 123 correctly, perhaps by double-buffering internally.  XXX provide more alg
 124 details here, or just leave it with the general idea?
 125
 126 3.3 TAPE FORMAT CHANGES
 127
 128 We need to specify the sequence number of the tape in the run,  in the tape
 129 header file.  The file header block specifies whether it is a continuation
 130 file or not.
 131
 132 3.4 TAPELIST FILE CHANGES
 133
 134 The lines in the tapelist file should contain the sequence number of the
 135 tape in its run, as well as the amount of data written on the tape, and
 136 perhaps whether or not the end of tape was reached.