Re: dumporder
On Tue, Nov 06, 2018 at 11:50:57AM -0500, Chris Nighswonger wrote: > Digging around a bit, it appears that it might be a reference to a > file which is missing. From amplot.g, line 62 we see: > > # file title has the parameters that this program needs > load 'title' > plot"run_queue" title "Run Queue" with lines,\ > "tape_queue" title "Tape Queue" with lines,\ > "finished" title "Dumps Finished" with lines,\ > "bandw_free" title "Bandwidth Allocated" with lines, \ > "disk_alloc" title "%Disk Allocated" with lines, \ > "tape_wait" title "%Tape Wait" with lines,\ > "tape_idle" title "Taper Idle" with lines,\ > "dump_idle" title "Dumpers Idle" with lines > > Where is a developer when you need one? :-P looks like the awk script is supposed to generate 'title'. on my system, I have to run amplot as user 'amanda'. that means that I have to be in a directory where amanda has write permission, otherwise title can't be generated. my home directory doesn't work, but a temp dir that's chmod 777 does. -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
Re: dumporder
On Tue, Nov 06, 2018 at 11:42:16AM -0500, Chris Nighswonger wrote: > The amplot utility is new to me. Here is what it says when I attempt to run > it: > > root@scriptor:~# amplot > /var/log/amanda/server/campus/amdump.20181106020001.debug > Displaying graph on the screen, for next graph : MISSING SPACE > DECLARATION > "title", line 62: Cannot open script file 'title' > > I have both gnuplot and gawk installed on the backup server. I have the same problem. the script 'amplot.g' says # file title has the parameters that this program needs load 'title' is the file 'title' supposed to be part of the distribution? -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
amrecover NAK problem
I'm trying to run amrecover locally on my amanda server called FQDN: sudo amrecover -s FQDN FQDN is running centos 7, and I have amanda 3.5 installed. I'm having this problem: AMRECOVER Version 3.5. Contacting server on FQDN ... NAK: user root from FQDN is not allowed to execute the service amindexd: Please add the line "FQDN root amindexd amidxtaped" to /var/lib/amanda/.amandahosts on the server I've done a lot of googling and tried adding a line like FQDN root amdump amindexd amidxtaped to .amandahosts, and that didn't work; then I tried just FQDN root which I think is supposed to allow all services, and that didn't work. (I put both of the 'root' lines at the top of .amandahosts just in case amanda is still quitting after the first match.) I changed the service file 'amanda@.service' to have the line ExecStart=/usr/sbin/amandad -auth=bsdtcp amdump amindexd amidxtaped and restarted, and that didn't help. I tried turning off the firewall on the server and that didn't help. not sure where else to look. -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
Re: amanda tape algorithm
On Thu, Jan 04, 2018 at 05:16:59PM -0700, Steven Backus wrote:
> Ned Danieley <ned.danie...@duke.edu> wrote:
>
> > ah, that makes sense. no, I haven't run 'amtapetype'; I just assumed that
> > the rated capacity would be accurate. I'll give it a try; in the meantime,
> > has anyone run 'amtapetype' on an LTO6 tape? I have an HP Ultrium 6 drive.
>
> I did and got:
>
> define tapetype LTO6 {
> comment "Created by amtapetype; compression disabled"
> length 2442954880 kbytes
> filemark 7456397 kbytes
> speed 154519 kps
> blocksize 32 kbytes
> }
thanks. that fairly well matches what I was using
define tapetype LTO6comp {
length 244352 kbytes
filemark 868 kbytes
speed 157129 kps
blocksize 2048 kbytes
}
except for filemark; can anyone comment on that? looking at the tapetype
definitions on the zmanda wiki, it seems that most of the LTO entries have
zero kbytes for filemark...
--
Ned Danieley (ned.danie...@duke.edu)
Department of Biomedical Engineering
Box 90281, Duke University
Durham, NC 27708 (919) 660-5111
http://dilbert.com/strips/comic/2012-02-11/
Re: amanda tape algorithm
On Thu, Jan 04, 2018 at 09:43:35PM +, Debra S Baddorf wrote: > > > On Jan 4, 2018, at 11:59 AM, Ned Danieley <ned.danie...@duke.edu> wrote: > > > > > > I'm using > > > > taperalgo largestfit > > > > which I assume means that amanda will write to tape the largest DLE > > available. I have 'runtapes' set to 2, and occasionally I'll see amanda > > move on to the second tape when the first tape is reporting around 80% full. > > I'm dumping almost 200 DLE, so it seems like there ought to be some DLEs > > that would fit in the remaining 20%. is there any way to find out (after > > the fact) what DLEs were in the queue? I've looked at the taper debug file > > but it just seems to have a list of each DLE as it is written. > > > > I'm using LTO6 tapes, so I should have about 2.5 TB to work with. I know > > about the ability to split DLEs, but I'm not ready to take that step. > > > > -- > > Ned Danieley (ned.danie...@duke.edu) > > Department of Biomedical Engineering > > Box 90281, Duke University > > Durham, NC 27708 (919) 660-5111 > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__dilbert.com_strips_comic_2012-2D02-2D11_=DwIGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=seIgoLdvEn-8badm2JmCmh78EJ9F9-Hw-LulwGbFPZI=DGzKNKCqh_8C-Y1Y3Smdu29gOMu_5Y82AnrH-oAP-vg=dB2_g2FDMHahFgcGA1CJLdbMwaXZJjrvHGFYP_pmwGM= > > > > > Did you actually test the size of your own tapes? (There’s a proceedure > that does this …. help me > out with the name, guys?) > > Amanda, I believe, uses your number to decide how much space is left on the > tape. It’ll > pick the biggest DLE that ought to fit in that spot (“largestfit”). If > you’ve over-estimated > the tape size, then this DLE will NOT fit. At that point, amanda can’t > back up and try > a smaller DLE. It merely stops trying with that DLE (saves it for later) > and moves on to > the next tape. > At this point, the “largestfit” is probably a bigger DLE, since the > whole tape is available > for the second tape. > > Rinse and repeat. > > So — maybe tell amanda a smaller size for the tape? Then it’ll try a > smaller “last” DLE, > and it will actually fit. > > At least, this is my understanding of how she works. ah, that makes sense. no, I haven't run 'amtapetype'; I just assumed that the rated capacity would be accurate. I'll give it a try; in the meantime, has anyone run 'amtapetype' on an LTO6 tape? I have an HP Ultrium 6 drive. -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
amanda tape algorithm
I'm using taperalgo largestfit which I assume means that amanda will write to tape the largest DLE available. I have 'runtapes' set to 2, and occasionally I'll see amanda move on to the second tape when the first tape is reporting around 80% full. I'm dumping almost 200 DLE, so it seems like there ought to be some DLEs that would fit in the remaining 20%. is there any way to find out (after the fact) what DLEs were in the queue? I've looked at the taper debug file but it just seems to have a list of each DLE as it is written. I'm using LTO6 tapes, so I should have about 2.5 TB to work with. I know about the ability to split DLEs, but I'm not ready to take that step. -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
Re: amanda planner and level 0 promotion
On Sat, Dec 30, 2017 at 03:02:05PM -0500, Jon LaBadie wrote: > On Sat, Dec 30, 2017 at 08:33:42AM -0500, Ned Danieley wrote: > > > > and on the other side of the coin, is there any way to encourage the planner > > to do more level 0 dumps in a given day? > > > > I occasionally find, often after a kernel update/reboot, that amanda > > thinks that a large number of DLE are 'new', and fairly quickly moves them > > up > > to level 2. but then the planner leaves them at L2 for days or weeks, at the > > same time using less than 1 TB of my 2.5 TB tape. > > > > I know that I can force a level 0, but that has to be done on each DLE. it > > seems like there should be a way to tell just amanda to use a larger > > fraction of the tape, but I can't figure it out. > > > > As an ideal, amanda tries to get consistant size dumps > each run of amdump. As an approximation this size can be > estimated (using post-compression data) as the sum of > all level 0's divided by the number of runs per dumpcycle > plus the average daily level 1 sizes. > > So you can get larger runs by three means, get more data > (bigger level 0's), become more active (bigger level 1's) > or shorten the dumpcycle (or runs/dumpcycle). okay, that's what I wanted to know. I'll try shortening the dumpcycle. thanks -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
amanda planner and level 0 promotion
On Fri, Dec 29, 2017 at 07:01:05PM -0500, Gene Heskett wrote: > > > While we are on this subject, why, with a 10 day cycle, working over 30 > vtapes of nominally 3.2 GB per vtape, does amanda's planner absolutely > refuse to use a level 2 or beyond? It often promotes a level 2 to a > level 0 when it has 6+ days left in its 10 day cycle. ... > > > Cheers, Gene Heskett and on the other side of the coin, is there any way to encourage the planner to do more level 0 dumps in a given day? I occasionally find, often after a kernel update/reboot, that amanda thinks that a large number of DLE are 'new', and fairly quickly moves them up to level 2. but then the planner leaves them at L2 for days or weeks, at the same time using less than 1 TB of my 2.5 TB tape. I know that I can force a level 0, but that has to be done on each DLE. it seems like there should be a way to tell just amanda to use a larger fraction of the tape, but I can't figure it out. -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
Re: amvault with dropbox
On Tue, Nov 07, 2017 at 01:29:34PM -0500, Austin S. Hemmelgarn wrote: > OK, so you're talking about functionally permanent archiving instead > of keeping old stuff around for a fixed multiple of the dump cycle. > If that's the case, you may be better off pulling the dumps off the > tapes using amfetchdump, and then uploading them for there. That > use case could in theory be handled better with some extra code in > Amanda, but I don't know how well the lack of deletion would be > handled on Amanda's side. yeah, I need to upload monthly full dumps to dropbox and keep them forever. the monthly dumps are to vtapes, and I thought it would be neat if I could then just transfer the vtapes to dropbox using amvault. -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
Re: amvault with dropbox
On Tue, Nov 07, 2017 at 01:11:43PM -0500, Austin S. Hemmelgarn wrote: > On 2017-11-07 11:55, Ned Danieley wrote: > > > >we use a dropbox business account to archive our data, and I was interested > >in trying to use amvault to transfer my amanda backups there. however, it > >seems that there is a fair amount of work that would have to be done to the > >code base to make that happen, work that is probably beyond my ability. > > > >are any plans to include dropbox access in future versions? > > > You can do this already without needing any new code. Just > configure a virtual tape library inside a Dropbox synced directory, > set that as a vaulting location, and recursively add the necessary > read permissions to the directory after each amvault run. I guess that would work, although I'd have to set up selective sync so I could remove the files locally without removing them from dropbox. thanks for the suggestion; I'll give it a try. -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
amvault with dropbox
we use a dropbox business account to archive our data, and I was interested in trying to use amvault to transfer my amanda backups there. however, it seems that there is a fair amount of work that would have to be done to the code base to make that happen, work that is probably beyond my ability. are any plans to include dropbox access in future versions? -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
problem with taper not changing tape, 3.4.[12]
I've found what appears to be a bug in the 3.4 release of amanda: under some circumstances, amanda overwrites a tape that was just written. an example from a backup to tape: These dumps were to tape RAIDsSet6-35. The next 2 tapes Amanda expects to use are: RAIDsSet6-36, RAIDsSet6-37. taper: tape RAIDsSet6-35 kb 2077738050 fm 308 [OK] taper: tape RAIDsSet6-35 kb 356540480 fm 61 [OK] as you can see, I have runtapes=2, and amanda seems to know that, yet it has overwritten the first part of the dump with the second. looking at the tape I've verified that there are only 61 files on tape 6-35. I made a test case using virtual tapes, and found the same thing: These dumps were to tape TEST-04. The next 2 tapes Amanda expects to use are: TEST-05, TEST-06. taper: tape TEST-04 kb 614240 fm 1 [OK] taper: tape TEST-04 kb 350240 fm 1 [OK] and the size of TEST-04 is indeed around 350G. any thoughts as to what's going on? the amanda.conf and disklist are the same ones I used under 3.3.x, and I didn't see this problem then. I've just joined this list, so I'm not sure about sending attachments (like amanda.conf). -- Ned Danieley (ned.danie...@duke.edu) Department of Biomedical Engineering Box 90281, Duke University Durham, NC 27708 (919) 660-5111 http://dilbert.com/strips/comic/2012-02-11/
