amanda v 3.5.1, Debian AMD64 Buster, Quantum STO-5, LSI SAS2008 PCIe card
I think I've found my problem. Amanda can't write big files to tape.
>From my Debian kernel.log (grep for st0):
Dec 13 15:41:34 sbox kernel: [ 2708.331836] st 0:0:2:0: [st0] Block limits 1 -
16777215 bytes.
Dec 13 15
Am 06.12.21 um 15:39 schrieb David Simpson:
Further to Jose's questions.
Some config excerpt may help.
On blocksize, that is defined within the tapetype.
blocksize 512 kbytes
And maybe try a run with amtapetype.
-users@amanda.org
Subject: Re: tape problem
I think the explanation for most of your problems is explained the amanda
report. I have some questions that may help find the problem:
- how much free space do you have on holding disk, how much space is
used?
- How big are the backups
compression on the tape?
Kind regards
Jose M Calhariz
On Fri, Dec 03, 2021 at 11:18:08PM +, ghe2001 wrote:
> amanda version: amadmin-3.5.1
> OS: Debian Linux, Buster
> Host: Supermicro
> PCI card: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2
> [Falcon] (rev 0
On Fri, 03 Dec 2021 23:18:08 +
ghe2001 wrote:
> Any ideas, explanations, fixes?
Maybe it's time to move to Bullseye?
Short of that, try a kernel from backports.
--
Does anybody read signatures any more?
https://charlescurley.com
https://charlescurley.com/blog/
Increasing the blocksize to 1024k achieved 284MB/sec uncompressed with
amtapetype
Have not changed kernel module (st) parameters or anything like that yet
Currently looking at the HP Library & Tape Tools ... it seems to want to test
with blocksizes of 32k-128k only
-
D
-
From: owner-amanda-us...@amanda.org On Behalf
Of Luc Lalonde
Sent: 28 September 2021 20:58
To: AMANDA users
Subject: Re: LTO8 tape profile - amtapetype
External email to Cardiff University - Take care when replying/opening
attachments or links.
Nid ebost mewnol o Brifysgol Caerdydd yw hwn
What tweaks did you do?
Yes, should of mentioned the server is dedicated for this purpose and is
reasonably resourced:
-dedicated SAS card for tape drives
-64GB RAM
-2x Xeon E5-2640 v3, so plenty of cores
-dedicated holding disk areas (RAID6) .. two of these coming in at approx.
32.7TB, which
drive on a Dell ML3 Tape Library.
On 2021-09-28 3:00 p.m., Chris Hoogendyk wrote:
You should get substantially faster. That said, throughput to the tape
will depend on a lot of things about your system and where the
bottleneck actually is. The maximum throughput of dual SAS2 is
6Gbit/s, which
You should get substantially faster. That said, throughput to the tape will depend on a lot of
things about your system and where the bottleneck actually is. The maximum throughput of dual SAS2
is 6Gbit/s, which would be 750MB/s. So, you aren't likely to come close to the 900MB/s
Just ran amtapetype against an LTO8 tape + HP MSL3040 (with SAS drives). Debian
11.
Some observations:
-compression on, expected
-length looks ok
-speed .. should I have expected more? Seemed a bit low I thought..
-no LEOM.. I don't know if it's the hardware or the Debian 11 kernel or both
Hello Folks,
Since LTO-4, we're supposed to be able to partition the tapes.
Is this supported by Amanda? If so, what tools are you using to
partition the tapes?
Thank You!
--
Luc Lalonde, analyste
-
Département de génie informatique:
École polytechnique de MTL
Nathan Stratton Treadway writes:
> On Fri, Sep 18, 2020 at 10:53:44 +0700, Olivier wrote:
>> I know there is amadmin no-reuse, but suppose the tape had been
>> completely destroyed and is not readable anymore, there should be a way
>> to tell Amanda it should completely f
On Fri, Sep 18, 2020 at 10:53:44 +0700, Olivier wrote:
> I know there is amadmin no-reuse, but suppose the tape had been
> completely destroyed and is not readable anymore, there should be a way
> to tell Amanda it should completely forget about that tape, remove any
> index it can ha
Probably not the official way, but you can delete it from
/etc/amanda//tapelist I realise that won't remove the index
information, but it will stop Amanda from wanting to consider the tape.
HTH,
Martin
On 18/09/2020 04:53, Olivier wrote:
Hi,
I have been trying to find the command opposite
Olivier writes:
> Hi,
>
> I have been trying to find the command opposite to amlabel: completely
> remove a tape from Amanda.
>
> I know there is amadmin no-reuse, but suppose the tape had been
> completely destroyed and is not readable anymore, there should be a way
>
Hi,
I have been trying to find the command opposite to amlabel: completely
remove a tape from Amanda.
I know there is amadmin no-reuse, but suppose the tape had been
completely destroyed and is not readable anymore, there should be a way
to tell Amanda it should completely forget about that tape
me that (at least on our Ubuntu Linux system) the
> smartmontools package's "smartctl" let us read error statistics
> information from the SCSI tape drive. I put
>
>smartctl -l error -H $TAPEDEV
Oh, interesting, I didn't know about this feature of smartctl.
Will try as soon as my n-th amtapetype finishes.
Am 15.05.20 um 13:59 schrieb Andreas Haumer:
> I think this was not mentioned on this thread yet, but
> there is also the HPE Library & Tape Tools utility ("ltt"),
> which allows to test many aspects of a tape drive.
> This software runs fine under Linux and can
me that (at least on our Ubuntu Linux system) the
> smartmontools package's "smartctl" let us read error statistics
> information from the SCSI tape drive. I put
>
>smartctl -l error -H $TAPEDEV
>
> in the cron script which ran Amanda, and it would produce ou
ctl" let us read error statistics
information from the SCSI tape drive. I put
smartctl -l error -H $TAPEDEV
in the cron script which ran Amanda, and it would produce output like
this:
==
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
H
Am 13.05.20 um 18:17 schrieb Stefan G. Weichinger:
> Now look at this run of
>
> "amtapetype -b 128k /dev/nst0"
>
> with another tape, FUJI instead of HP:
>
> define tapetype LTO3-fuji {
> comment "Created by amtapetype; compression disa
There was a discussion back in 2014 with subject "Backups to tape
consistently under 60% tape capacity". I haven't read the whole lengthy
thread but one participant mentioned that in his case a bad cleaning
tape was found to be responsible for the capacity loss. Others reported
tha
GB written.
> >
> > I don't see any interrupted writing or so (until that End Of Tape).
>
> (We switched to disk-drive vtapes a long time ago so when I was last
> looking into the details of backup-tape-drive behavior it was probably
> for pre-LTO technology, but I
Glad you brought up this "feature" Nathan. I had heard it before
but not using tape, promptly forgot it.
Jon
On Thu, May 14, 2020 at 05:30:53PM -0400, Nathan Stratton Treadway wrote:
> On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote:
> > Interesting, how
On Thu, May 14, 2020 at 09:14:17 +0200, Stefan G. Weichinger wrote:
> Interesting, how can a "dirty" drive trigger this behavior?
>
> I'd expect failures all along and not after ~200 or 300 GB written.
>
> I don't see any interrupted writing or so (until that End Of Tape
On Thu, May 14, 2020 at 09:14:17AM +0200, Stefan G. Weichinger wrote:
> Am 14.05.20 um 07:59 schrieb Jens Berg:
> > There was a discussion back in 2014 with subject "Backups to tape
> > consistently under 60% tape capacity". I haven't read the whole lengthy
> > threa
On Thursday 14 May 2020 01:32:05 Jon LaBadie wrote:
> On Wed, May 13, 2020 at 06:17:02PM +0200, Stefan G. Weichinger wrote:
> > Now look at this run of
> >
> > "amtapetype -b 128k /dev/nst0"
> >
> > with another tape, FUJI instead of HP:
> >
&g
Am 14.05.20 um 07:59 schrieb Jens Berg:
> There was a discussion back in 2014 with subject "Backups to tape
> consistently under 60% tape capacity". I haven't read the whole lengthy
> thread but one participant mentioned that in his case a bad cleaning
> tape was f
hat said need for cleaning
> is one reason for getting early EOM.
>
> I'm wondering also if this could be a case of Amanda tapes being
> labelled with the mode set to LTO-2 capacity. I know you check
> the mode and it shows 44, but Amanda always reads the tape before
> writing
On Wed, May 13, 2020 at 06:17:02PM +0200, Stefan G. Weichinger wrote:
> Now look at this run of
>
> "amtapetype -b 128k /dev/nst0"
>
> with another tape, FUJI instead of HP:
>
> define tapetype LTO3-fuji {
> comment "Created by amtapetype;
> On May 13, 2020, at 11:17 AM, Stefan G. Weichinger wrote:
>
> Now look at this run of
>
> "amtapetype -b 128k /dev/nst0"
>
> with another tape, FUJI instead of HP:
>
> define tapetype LTO3-fuji {
>comment "Created by amtapetype; co
Now look at this run of
"amtapetype -b 128k /dev/nst0"
with another tape, FUJI instead of HP:
define tapetype LTO3-fuji {
comment "Created by amtapetype; compression disabled"
length 284180096 kbytes
filemark 20803 kbytes
speed 38376 kps
Am 13.05.20 um 09:03 schrieb Stefan G. Weichinger:
> It looks like a LTO2 tape ... although the customer told me it says LTO3
> on the cartridge (and has a correct product number).
>
> mt status detects it as density=0x44 as well, but the capacity and speed
> looks like LTO2.
>
Retried amtatpetype with another new tape yesterday.
No success.
Labelled and tested with 64k blocksize, still about 200 GB size only.
Could the older kernel somehow play a role here?
The output of amtapetype says:
"LEOM is not supported for this drive and kernel"
I try to set &
Am 12.05.20 um 14:10 schrieb Stefan G. Weichinger:
> Maybe they bought LTO2 tapes, I check that asap.
No, the tapes are OK.
HP LTO3 C7973A
I googled some stinit.def and set:
# cat /etc/stinit.def
# HP StorageWorks Ultrium 960/920 SAS LTO-3
manufacturer="HP" model = "Ultrium 3-SCSI" {
Am 12.05.20 um 08:34 schrieb Stefan G. Weichinger:
> backups run to a LTO3 tape (remember, 400 GB uncompressed space per
> definition)
I ran amtapetpye and only get half of the expected capacity!
why that ...
$ amtapetype -t LTO3_2020 -f /dev/nst0
Checking for FSF_AFTER_FILEMARK requi
ent SUSE Linux and
amanda-2.4.0 ... that VM is "read only" in terms of upgrades etc
Things work so far, and I assume my issue is not related to the VM.
The point is:
backups run to a LTO3 tape (remember, 400 GB uncompressed space per
definition)
And when I run a "weekly" run
Jens Berg writes:
> On 8/28/2019 9:14 AM, Olivier wrote:
>> I have a dedicated server that runs Amanda, with 8 bays, I never
>> disconnect the disks unless it is time to replace them with a newer
>> and biger one.
>
> Don't you have Off-Site backups?
No.
> Since I switched from LTO to vtapes,
On 8/28/2019 9:14 AM, Olivier wrote:
> I have a dedicated server that runs Amanda, with 8 bays, I never
> disconnect the disks unless it is time to replace them with a newer
> and biger one.
Don't you have Off-Site backups?
Since I switched from LTO to vtapes, I'm using USB drives for that which
Diego Zuccato writes:
> Il 28/08/19 03:34, Olivier ha scritto:
>
>> Or write another device for Amanda to use, it would not be vtape, it
>> would be ... something.
> Could be 'rawdisk'. :)
>
> But better plan for some redundancy to compensate for silent corruption.
>
> And consider that SATA
Il 28/08/19 03:34, Olivier ha scritto:
> Or write another device for Amanda to use, it would not be vtape, it
> would be ... something.
Could be 'rawdisk'. :)
But better plan for some redundancy to compensate for silent corruption.
And consider that SATA connectors have a limited life (about
Gene Heskett writes:
> On Monday 26 August 2019 23:55:31 Olivier wrote:
>
>> Gene Heskett writes:
>> > Generally speaking, only because the disc is random access.
>>
>> But a disk dedicated to vtapes should be doing a lot of sequetial
>> accesses: once it has been formatted and the slots have
Diego Zuccato writes:
> Il 27/08/19 05:55, Olivier ha scritto:
>
>> But a disk dedicated to vtapes should be doing a lot of sequetial
>> accesses: once it has been formatted and the slots have been assigned,
>> it is writting files the size of one Amanda's chunk. In fact, that would
>> be worth
Jon LaBadie writes:
> On Tue, Aug 27, 2019 at 11:44:02AM +0200, Diego Zuccato wrote:
>> Il 27/08/19 05:55, Olivier ha scritto:
>>
>> > But a disk dedicated to vtapes should be doing a lot of sequetial
>> > accesses: once it has been formatted and the slots have been assigned,
>> > it is
On Tue, Aug 27, 2019 at 11:44:02AM +0200, Diego Zuccato wrote:
> Il 27/08/19 05:55, Olivier ha scritto:
>
> > But a disk dedicated to vtapes should be doing a lot of sequetial
> > accesses: once it has been formatted and the slots have been assigned,
> > it is writting files the size of one
Il 27/08/19 05:55, Olivier ha scritto:
> But a disk dedicated to vtapes should be doing a lot of sequetial
> accesses: once it has been formatted and the slots have been assigned,
> it is writting files the size of one Amanda's chunk. In fact, that would
> be worth a study: the disk usage for
On Monday 26 August 2019 23:55:31 Olivier wrote:
> Gene Heskett writes:
> > Generally speaking, only because the disc is random access.
>
> But a disk dedicated to vtapes should be doing a lot of sequetial
> accesses: once it has been formatted and the slots have been assigned,
> it is writting
Gene Heskett writes:
> Generally speaking, only because the disc is random access.
But a disk dedicated to vtapes should be doing a lot of sequetial
accesses: once it has been formatted and the slots have been assigned,
it is writting files the size of one Amanda's chunk. In fact, that would
be
On Monday 26 August 2019 21:42:29 Olivier wrote:
> ghe writes:
> > Stan and Debra have convinced me to bite the bullet and buy a new
> > tape. I've never been in this situation before (the DLT drive used
> > to fail every once in a while, but a couple hours with a jeweler'
On Mon, 26 Aug 2019 16:01:58 -0400
Gene Heskett wrote:
> But AFAIK, tapes don't maintain an allocation map, and we have no
> tape writing tools so organized as to be able to implement such a
> scheme.
Not entirely true.
Tape drives such as Colorado Memory Systems' QIC drives were rand
ghe writes:
> Stan and Debra have convinced me to bite the bullet and buy a new tape.
> I've never been in this situation before (the DLT drive used to fail
> every once in a while, but a couple hours with a jeweler's screwdriver
> got it going again).
>
> Looks like I'm goi
On 8/26/19 5:20 PM, Nathan Stratton Treadway wrote:
> I haven't looked closely at tape drives in a few years, but others on
> this list certainly have in-depth experience with them. I think some of
> the specific answers do depend on what tape-drive technology/generation
> you a
Cheap is defined in comparison with “how long will it take to recreate all that
data by hand,
if it’s lost”. The value of that may depend on your reason for doing a backup.
Deb Baddorf
Fermilab
> On Aug 26, 2019, at 6:39 PM, ghe wrote:
>
> On 8/26/19 4:16 PM, stan wrote:
>
>> Tapes are
On 8/26/19 2:01 PM, Gene Heskett wrote:
> I did that once for a very old hard drive, permanently allocating about
> 30 sectors to a file named badsectors.fd. Worked great.
That's a clever idea...
> But AFAIK, tapes don't maintain an allocation map, and we have no tape
> writ
On 8/26/19 4:16 PM, stan wrote:
> Tapes are cheap!
Define 'cheap' :-)
There's a significant difference between what Google and I consider cheap...
> What technology BTW.
LTO-5
I'm a newcomer from the DLT world. Those were reasonably cheap by my
definition...
--
Glenn English
On Fri, Aug 16, 2019 at 11:38:45 -0600, ghe wrote:
> I have reason to believe that one of my tapes isn't working properly
> (last night's backup died without finishing because of a tape error --
> the retry running right now successfully flushed last night's and wrote
> a new one)
On Friday 16 August 2019 13:38:45 ghe wrote:
> I have reason to believe that one of my tapes isn't working properly
> (last night's backup died without finishing because of a tape error --
> the retry running right now successfully flushed last night's and
> wro
Try “man amcheckdump” It might give you what you want.
Deb Baddorf
Fermilab
> On Aug 16, 2019, at 12:38 PM, ghe wrote:
>
> I have reason to believe that one of my tapes isn't working properly
> (last night's backup died without finishing because of a tape error --
> the retr
I have reason to believe that one of my tapes isn't working properly
(last night's backup died without finishing because of a tape error --
the retry running right now successfully flushed last night's and wrote
a new one).
Is there an Amanda utility that will validate a tape without destroying
Check `man amanda.conf`. There is an option "eject-volume" which defaults to
no, but can be set to yes.
On 7/28/19 6:15 AM, Stefan G. Weichinger wrote:
What's the current howto here?
I don't see a matching PROPERTY for the device "Tape device" here
https://wiki.zmanda.co
On 7/28/19 4:15 AM, Stefan G. Weichinger wrote:
> Customer wishes to have all tapes ejected in the morning.
I've written a shell script that, among other things, runs amdump then
mt eject (one tape). It's done what you're looking to do for a couple
decades.
--
Glenn English
What's the current howto here?
I don't see a matching PROPERTY for the device "Tape device" here
https://wiki.zmanda.com/man/amanda-devices.7.html
Customer wishes to have all tapes ejected in the morning.
OK, I could run a cron job, but what if amdump isn't done yet?
something li
On Wednesday 29 May 2019 06:37:49 pm Charles Curley wrote:
> On Wed, 29 May 2019 17:49:56 -0400
>
> Gene Heskett wrote:
> > On Wednesday 29 May 2019 05:00:22 pm Charles Curley wrote:
> > > Gene's query on the recipe for extracting in the tape headers got
> >
On Wed, 29 May 2019 17:49:56 -0400
Gene Heskett wrote:
> On Wednesday 29 May 2019 05:00:22 pm Charles Curley wrote:
>
> > Gene's query on the recipe for extracting in the tape headers got me
> > curious. The few I looked at were complete backups. However, I also
> > spli
On Wednesday 29 May 2019 05:00:22 pm Charles Curley wrote:
> Gene's query on the recipe for extracting in the tape headers got me
> curious. The few I looked at were complete backups. However, I also
> split my backups into chunks. Those did not have a suitable command
> line, and
Gene's query on the recipe for extracting in the tape headers got me
curious. The few I looked at were complete backups. However, I also
split my backups into chunks. Those did not have a suitable command
line, and I'm not sure you could automate one for inclusion in the
header.
The algorithm
out to 32kiB...
>
> =
> root@tumhalad:~/rushey_etc_git# hd
> /vtapes/TestBackup/slot1/0.TESTBACKUP-01 41 4d 41 4e 44
> 41 3a 20 54 41 50 45 53 54 41 52 |AMANDA: TAPESTAR| 0010 54 20
> 44 41 54 45 20 32 30 31 38 31 31 30 38 30 |T DATE 201811080|
> 0020
4d 41 4e 44 41 3a 20 54 41 50 45 53 54 41 52 |AMANDA: TAPESTAR|
0010 54 20 44 41 54 45 20 32 30 31 38 31 31 30 38 30 |T DATE 201811080|
0020 37 30 31 30 33 20 54 41 50 45 20 54 45 53 54 42 |70103 TAPE TESTB|
0030 41 43 4b 55 50 2d 30 31 0a 0c 0a 00 00 00 00 00 |ACKUP-01...
On Tuesday 28 May 2019 12:49:05 pm Charles Curley wrote:
> On Tue, 28 May 2019 11:40:33 -0400
>
> Gene Heskett wrote:
> > In my build on stretch the tape header, with normally contains
> > instructions for a gzip/tar only system, the recipe for bare
> > recovery has
Agreed - the short form is: the tape header needs no instructions,
and each DLE file might be done with a different mechanism (true for me) so
each DLE backup has the instructions in the header.
Deb Baddorf
Fermilab
> On May 28, 2019, at 11:49 AM, Charles Curley
> wrote:
>
>
On Tue, 28 May 2019 11:40:33 -0400
Gene Heskett wrote:
> In my build on stretch the tape header, with normally contains
> instructions for a gzip/tar only system, the recipe for bare recovery
> has disappeared. It now looks like this:
> AMANDA: TAPESTART DATE 20190527162707 T
In my build on stretch the tape header, with normally contains
instructions for a gzip/tar only system, the recipe for bare recovery
has disappeared. It now looks like this:
AMANDA: TAPESTART DATE 20190527162707 TAPE Dailys-1
There is supposed to be a 2nd line, showing how to unpack
57 -0600, Charles Curley wrote:
> >
> > Here's what I do to customize:
> >
> > cp -rp /var/lib/amanda/example/amanda.conf ${confDir}
> >
> > # Now adjust the configuration to suit.
> > cd ${confDir}
> > sed -i -e
> > "s/tape:\/dev\/YOUR-TAPE-DEVICE-HE
ample/amanda.conf ${confDir}
>
> # Now adjust the configuration to suit.
> cd ${confDir}
> sed -i -e
> "s/tape:\/dev\/YOUR-TAPE-DEVICE-HERE/chg-disk:\/var\/amanda\/vtapes/"
> amanda.conf
> sed -i -e 's/tapetype HP-DAT/tapetype HARD-DISK/' amanda.conf
>
> And
o through
> > the process with no issue as to which tape device to use and get a
> > good extraction.
> >
> > Using the git package, I have to specify the tape device like so:
> >
> > amrecover -d chg-disk:/var/amanda/vtapes -C DailySet1
> >
> > If
On Wed, May 15, 2019 at 17:02:57 -0600, Charles Curley wrote:
> Using the official debian packages, I am accustomed to CDing to the
> desired directory, and entering "amrecover DailySet1". I go through the
> process with no issue as to which tape device to use and get
Using the official debian packages, I am accustomed to CDing to the
desired directory, and entering "amrecover DailySet1". I go through the
process with no issue as to which tape device to use and get a good
extraction.
Using the git package, I have to specify the tape device like so:
Am 22.01.19 um 18:50 schrieb Stefan G. Weichinger:
>
> I might have written about that already some years(?) ago, but anyway:
>
> I have a small shell-script to ask "amadmin config tape --days X" for
> the next tapes to put into the magazines.
>
> That sc
I might have written about that already some years(?) ago, but anyway:
I have a small shell-script to ask "amadmin config tape --days X" for
the next tapes to put into the magazines.
That script is run via cron and emails the local admin at the customer
with the requested tapes.
On Tue, Jan 15, 2019 at 05:33:55PM -0500, Jon LaBadie wrote:
> On Tue, Jan 15, 2019 at 07:38:37PM +, Debra S Baddorf wrote:
> > Amanda people: does the newer amanda have any means to dump to tape
> > while still retaining a copy on the holding disk?
> >
> > Dumping
On Tue, Jan 15, 2019 at 07:38:37PM +, Debra S Baddorf wrote:
> Amanda people: does the newer amanda have any means to dump to tape
> while still retaining a copy on the holding disk?
>
> Dumping to tape, and then vaulting BACK to a disk area seems excessive,
> if there
Amanda people: does the newer amanda have any means to dump to tape
while still retaining a copy on the holding disk?
Dumping to tape, and then vaulting BACK to a disk area seems excessive,
if there is a better way?
Deb Baddorf (asking for Stefan Weichinger)
> On Jan 15, 2019, at 1:34
ger.
> Suppose I have 3 "departments", sales, research,
> and support.
>
> Could I create 3 dumptype definitions so that
> all "sales" DLEs are backed up to a tape pool
> consisting of vtapes 1-80, "research" to vtapes
> 81-160, and "suppor
I believe that you would define tape pool of 80 for each, with regular
expressions you may be able to have the same label string format but different
tape number ranges.
Maybe like this?
Sales POOL1[0-9][0-9]
Support POOL2[0-9][0-9]
Research POOL3[0-9][0-9]
For sanity I think I'd define 3 tape
I currently have 240 Vtapes in a single changer.
Suppose I have 3 "departments", sales, research,
and support.
Could I create 3 dumptype definitions so that
all "sales" DLEs are backed up to a tape pool
consisting of vtapes 1-80, "research" to vtapes
81-160, a
tape drive commands before amdump/amcheck/amflush starts
Hi,
before above amanda programs are started, 2 mt(1) commands are executed
("datcompression 0" & "setblk 32768"). At present, I do this with cron
jobs just before the amanda program starts (or
Hi,
before above amanda programs are started, 2 mt(1) commands are executed
("datcompression 0" & "setblk 32768"). At present, I do this with cron
jobs just before the amanda program starts (or manually in other cases),
but is there a simple way to integrate this somewhere in amanda? E.g.
rks and the later ones stop working with
---
Hostname: chronos
Org : a2g-2
Config : a2g-2
Date: May 17, 2018
*** A TAPE ERROR OCCURRED: [no drives available].
Some dumps may have been left in the holding disk.
The next 3 tapes Amanda expects to use are: a2g-2-03, a2g-2-09, a2
That worked fine, thanks.
Ian
On 04/12/2018 05:59 PM, Jean-Louis Martineau wrote:
> Ian,
>
> Can you try to use the "amgtar" application instead of the GNUTAR program?
>
> Jean-Louis
13 PM
To: amanda-users@amanda.org
Subject: sendbackup deadlock for my direct-to-tape dump
So I switched out my backup server to a new host running Ubuntu 18.04 (Bionic
Beaver). All the Amanda stuff is working OK except for the localhost root
filesystem dump, which is done direct to tape (no holding
So I switched out my backup server to a new host running Ubuntu 18.04
(Bionic Beaver). All the Amanda stuff is working OK except for the
localhost root filesystem dump, which is done direct to tape (no holding
disk). That one hangs for a while, then fails with the error
"sendbackup: cri
with the expected
JM> result:
OK, it's good to know that at some point it's worked for someone. I was
using "flush-threshold-scheduled 70" and "flush-threshold-dumped 90" but
it would always flush if there was data to flush even if it only filled
a small portion of the tape.
Hi Jason,
* Jason L Tibbitts III <ti...@math.uh.edu> [20180314 11:33]:
> And so it turns out that if you turn off autoflush, Amanda will never
> flush existing dumps to tape regardless of the flush-threshold-*
> settings. Which I guess makes sense. And with "autoflush yes&qu
And so it turns out that if you turn off autoflush, Amanda will never
flush existing dumps to tape regardless of the flush-threshold-*
settings. Which I guess makes sense. And with "autoflush yes", it
seems to simply flush everything currently on the holding disk
regardless of othe
problem is that I
asked for at least 70% usage and it's giving me just about 50%. I also
checked the logs and it seems that it basically flushes every other day,
which is consistent with it always flushing existing dumps to tape at
startup. So I'll turn off autoflush and see if that makes any
difference.
- J<
> On Mar 9, 2018, at 1:43 PM, Jason L Tibbitts III <ti...@math.uh.edu> wrote:
>
> With tape sizes what they are now I'm finally at the point where I have
> way more tape than stuff to back up. To satisfy my inherent laziness,
> I'd like to actually fill every tape (o
With tape sizes what they are now I'm finally at the point where I have
way more tape than stuff to back up. To satisfy my inherent laziness,
I'd like to actually fill every tape (or at least come close to filling
them). And then just leave my library full of tapes without ever
needing to change
On Wed, Dec 27, 2017 at 17:26:04 -0500, Jean-Louis Martineau wrote:
> 'amadmin tape' list the oldest reusable label, it doesn't use the
> taperscan algorithm and it doesn't check what is currently loaded in the
> changer.
> 'amcheck' and 'amtape' run the taperscan algorith
Am 2018-01-18 um 11:19 schrieb Volker Jahns:
> We have a customer request to implement a backup system which
> incorporates a Fujitsu eternus lt20 tape library.
>
> Is there any experience on operating this tape library with amanda? Any
> help would be greatly appreciated.
In g
1 - 100 of 4500 matches
Mail list logo
