On Tue, 14 May 2019 at 22:14, Nathan Stratton Treadway <natha...@ontko.com> wrote:
Hi Nathan, Thanks for you reply and help. On Mon, May 13, 2019 at 09:59:13 +1000, Tom Robinson wrote: > > I have a weekly backup that backs-up the daily disk based backup to tape > (daily's are a separate > > amanda config). > > (As a side note: if you are running Amanda 3.5 you might consider using > vaulting to do this sort of backup, so that Amanda knows about the > copies that are put onto the tape.) > > Unfortunately, no. We're on 3.3.3. Considering updating that on an Illumos variant (OmniOS CE)... looks like I may have to compile a custom package. Originally I installed a CSW package but I haven't seen any updates for that as of yet. > > Occasionally on the weekly backup a DLE will fail to dump writing only a > 32k header file before > > timing out. > > > > I can't seem to identify the error when looking in logging. Has anyone a > few clues as to what to > > look for? > > > > FAILURE DUMP SUMMARY: > > monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [data > timeout] > > monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [dumper > returned FAILED] > > monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [data > timeout] > > monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [dumper > returned FAILED] > > [...] > > > > A while ago I changed estimate to calcsize as the estimates were taking > a very long time and all > > daily slots are a know maximum fixed size. I thought it might help with > time outs. Alas not. > > Amanda's estimate timeouts are separate from data timeouts; changing to > calcsize will help with the former but not the latter. (Note that if > the slots are really a known size, using "server" estimate is even > faster than "calcsize", since it then just uses the size from the > previous run and doesn't read through the current contents of the DLE > directory to add up the sizes.) > > You can control the data timeouts with the "dtimeout" parameter in > amanda.conf. Just try bumping that up so that you are sure it's longer > than a dump actually takes. > My dtimeout was set to half an hour. After I check some logs and found the average dump time for my DLEs was around 55 minutes I've adjusted the dtimeout to 1hour. The last run went well so I'm waiting on the next run to see if it's consistent. > (The sendbackup.<DATETIME>.debug and runtar.<DATETIME>.debug client log > files should confirm that the GNU tar is running without error but then > unable to write to the output pipe on the server side. In the server > logs, I think the 'data timeout reached, aborting'-sort of message would > be found in the dumper.<DATETIME>.debug file for that run...) > yes, that helps knowing where to look! I am getting a new issue now which is annoying but not a show stopper. I think I will have to revisit my threshold settings to fix this but maybe you can offer some insight. I have a tape robot and the following settings in amanda.conf runtapes 3 flush-threshold-dumped 100 flush-threshold-scheduled 100 taperflush 100 autoflush yes There is enough room for all the data to go on three tapes yet after the amdump run is complete only two tapes are written and I am left to flush the remaining dumps to tape manually. I think it's because I'm trying to get a whole tape's worth of data before writing to tape. Is my thinking correct? What I'd like to do is make sure there's a tape's worth of data to write to the first two tapes in turn and then dump all remaining backup data to tape three (this will not be a complete tapes worth). Should I be setting taperflush as follows to achieve this? taperflush 0 Kind regards, Tom
