Re: LTO 6 Tapetype?
On Wednesday, 25.06.2014 at 11:37 +0200, Sven Rudolph wrote: > [...] > > One more reason for using amtapetype: It gives you some basic testing > of your new hardware and configuration. It's also worth running amtapetype more than once, with different tapes (and different drives, if you have more than one 'identical' model), in my experience. The results should be the same. Dave. -- Dave Ewart da...@ceu.ox.ac.uk Computing Manager, Cancer Epidemiology Unit University of Oxford N 51.7516, W 1.2152 signature.asc Description: Digital signature
Re: Why have my tapes 'shrunk' in size?
On Wednesday, 12.03.2014 at 14:38 +, Dave Ewart wrote:
> Hello,
>
> Four years ago I deployed a pair of Tandberg LTO-5 Ultrium (SAS) tape,
> connected a Dell PowerEdge server via a Dell H200 SAS controller.
>
> At that time ran the amtapetype utility which produced this output:
>
> define tapetype Tandberg-LTO5 {
> comment "Tandberg LTO5 1500/3000, produced by tapetype prog (hardware
> compression off)"
> length 1410 gbytes
> filemark 0 kbytes
> speed 125762 kps
> }
>
> (That was created by an older version of AMANDA, which we were using at
> the time: probably from Debian/Lenny, which was version 2.5.2p1, I
> believe)
>
> These tapes are native 1.5TB and so that looks pretty reasonable. We've
> never used these tapes to their fullest capacity and all was fun and
> shiny until recently when the tapes reported "No space left on device".
> However, the concerning thing is that the tapes reported 'full' at less
> than what I was expecting as full capacity, just above 1.1TB in fact.
> This means that our backup space 'growth', which I had been assuming was
> only 75%/80% full is in fact at 100%!
>
> [...]
>
> What's going on? Why am I not getting to use the full capacity??
Just to follow up on this one: I was able to purchase two, replacement
identical tape drives and with the new drives the full tape capacity is
available. I have therefore assigned the above anomaly to the old tape
drives having worn heads or similar.
Cheers,
Dave.
--
Dave Ewart
da...@ceu.ox.ac.uk
Computing Manager, Cancer Epidemiology Unit
University of Oxford
N 51.7516, W 1.2152
signature.asc
Description: Digital signature
Re: Why have my tapes 'shrunk' in size?
On Wednesday, 12.03.2014 at 13:11 -0400, Brian Cuttler wrote: > Don't know if its relevant, but I've got an LTO5/juke and it dropped > in both speed and capacity. Interesting: was it a gradual decrease in performance or was there a sudden drop? Dave. -- Dave Ewart da...@ceu.ox.ac.uk Computing Manager, Cancer Epidemiology Unit University of Oxford N 51.7516, W 1.2152 signature.asc Description: Digital signature
Re: Why have my tapes 'shrunk' in size?
On Wednesday, 12.03.2014 at 12:28 -0400, Jon LaBadie wrote: > A guess only. > > I note the measured speed has dropped by 45%. Due to what I haven't a > clue, but maybe some hardware change or cables or ??? Hmmm, yeah: I noticed that too, just after I'd posted. It's the same controller card as always and the same cables, so it's either a driver issue with the controller (OS has been upgraded once or twice) or a fault with the controller or damage to the cable, maybe. > Perhaps your system's ability to feed the drive has dropped below the > minimum needed to keep the drive streaming. In that case, the drive > must "shoe-shine" and each restart costs a bit of tape. Would this behaviour be noticeable just by looking at the drive in operation, do you think, seeing some kind of stop and start? Backups normally run during 'out of hours', but I can run a job while physically sat in the room with the drive... Dave. -- Dave Ewart da...@ceu.ox.ac.uk Computing Manager, Cancer Epidemiology Unit University of Oxford N 51.7516, W 1.2152 signature.asc Description: Digital signature
Why have my tapes 'shrunk' in size?
Hello,
Four years ago I deployed a pair of Tandberg LTO-5 Ultrium (SAS) tape,
connected a Dell PowerEdge server via a Dell H200 SAS controller.
At that time ran the amtapetype utility which produced this output:
define tapetype Tandberg-LTO5 {
comment "Tandberg LTO5 1500/3000, produced by tapetype prog (hardware
compression off)"
length 1410 gbytes
filemark 0 kbytes
speed 125762 kps
}
(That was created by an older version of AMANDA, which we were using at
the time: probably from Debian/Lenny, which was version 2.5.2p1, I
believe)
These tapes are native 1.5TB and so that looks pretty reasonable. We've
never used these tapes to their fullest capacity and all was fun and
shiny until recently when the tapes reported "No space left on device".
However, the concerning thing is that the tapes reported 'full' at less
than what I was expecting as full capacity, just above 1.1TB in fact.
This means that our backup space 'growth', which I had been assuming was
only 75%/80% full is in fact at 100%!
I re-ran the tapetype utility from our current AMANDA (version 2.6.1p2-3
from Debian/Squeeze) and it showed this:
define tapetype unknown-tapetype {
comment "Created by amtapetype; compression disabled"
length 1148746080 kbytes
filemark 0 kbytes
speed 69815 kps
blocksize 32 kbytes
}
The length reported here is ~1.1TB which ties up with the "no space left
on device" message, but ...
... these are genuine LTO-5 (Tandberg brand) tapes - just like
http://img.misco.eu/Resources/images/Modules/InformationBlocks/1210/TAN/TAN-2/202175-tandberg-LTO-5-tape-cartridge-small.jpg
- and the second tapetype above was created using a previously-unused
tape and they really are 1.5TB native!
What's going on? Why am I not getting to use the full capacity??
Cheers,
Dave.
--
Dave Ewart
da...@ceu.ox.ac.uk
Computing Manager, Cancer Epidemiology Unit
University of Oxford
N 51.7516, W 1.2152
signature.asc
Description: Digital signature
Can anyone explain this log error message?
1321660183.519872: runtar: config: Daily 1321660183.520622: runtar: pid 2400 ruid 0 euid 0 version 2.6.1p2: rename at Fri Nov 18 23:49:43 2011 1321660183.520836: runtar: running: /bin/tar --create --file /dev/null --numeric-owner --directory /home --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/athena_home_5.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendsize._home.2018234943.exclude . 1321660183.520853: runtar: pid 2400 finish time Fri Nov 18 23:49:43 2011 No obvious error recorded there. Can someone explain why the above situation results in a hard error? Am happy to supply further log extracts if required. I appreciate that AMANDA development is now concentrated on the 3.x series and that I may receive some suggestions to upgrade: however, I prefer to use distribution-supplied packages where possible. And, in our experience, this has always worked very reliably in the past. Thanks, Dave. -- Dave Ewart da...@ceu.ox.ac.uk Computing Manager, Cancer Epidemiology Unit University of Oxford / Cancer Research UK N 51.7516, W 1.2152
Can anyone explain this log error message?
1321660183.519872: runtar: config: Daily 1321660183.520622: runtar: pid 2400 ruid 0 euid 0 version 2.6.1p2: rename at Fri Nov 18 23:49:43 2011 1321660183.520836: runtar: running: /bin/tar --create --file /dev/null --numeric-owner --directory /home --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/athena_home_5.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendsize._home.2018234943.exclude . 1321660183.520853: runtar: pid 2400 finish time Fri Nov 18 23:49:43 2011 No obvious error recorded there. Can someone explain why the above situation results in a hard error? Am happy to supply further log extracts if required. I appreciate that AMANDA development is now concentrated on the 3.x series and that I may receive some suggestions to upgrade: however, I prefer to use distribution-supplied packages where possible. And, in our experience, this has always worked very reliably in the past. Thanks, Dave. -- Dave Ewart da...@ceu.ox.ac.uk Computing Manager, Cancer Epidemiology Unit University of Oxford / Cancer Research UK N 51.7516, W 1.2152 signature.asc Description: Digital signature
Re: Encrypted backups on FreeBSD ?
On Thursday, 03.04.2008 at 09:29 -0400, Matthew Moffitt wrote: > I've been through this but still don't have it working. On the > particular disk entry (backing up with gtar) encryption doesn't run > during amdump. amcheck reports the error: > > WARNING: testhost:/disk1/user/srl does not support server data > encryption It sounds counter intuitive, but you may need to check the version of the AMANDA *client* supports "server-side" encryption. You probably need 2.5.1 or above. I was confused by this, initially, thinking "why does the client need to support encryption when I'm doing the encryption server-side?". Apparently, from reading the source code, my understanding is that AMANDA tries to figure out which facilities are supported by the client and bombs out as above in those circumstances. I'm just wondering whether this is a bug in AMANDA, or whether there is a good reason for AMANDA to insist that the client 'supports' server-side encryption ... ? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit University of Oxford / Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: Encrypted backups on FreeBSD ?
On Wednesday, 02.04.2008 at 16:54 -0500, Nomad wrote:
> I'm having some strange issues as well, trying to do encrypted backups on
> FreeBSD. Let me ask this:
>
> 1. Is encrypted storage of backups a production feature?
I got this working without too much of a problem.
1. Create a key file and a passphrase as described in 'man amcrypt',
store them in the locations indicated.
2. Use a config such as the following to perform the actual encryption:
define dumptype whatever {
# [... other settings ...]
encrypt server
server_encrypt "/usr/sbin/amcrypt"
}
Dave.
--
Dave Ewart
[EMAIL PROTECTED]
Computing Manager, Cancer Epidemiology Unit
University of Oxford / Cancer Research UK
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc
N 51.7518, W 1.2016
signature.asc
Description: Digital signature
Re: Define what holding disk to use?
On Thursday, 06.03.2008 at 16:05 -0800, Aaron J. Grier wrote: > On Tue, Mar 04, 2008 at 08:29:03AM -0500, Chris Hoogendyk wrote: > > My own preference is to configure the system with separate drives > > for holding disk. There is no reason for them to be raid. > > all backup data passes through the holding disk: doesn't it follow > that the holding disk should be as reliable as possible? and doesn't > that imply at least a mirrored holding disk? MTBF may be lowered, but > failure of a single holding disk will not affect backups. I'm quite happy to use a fast, RAID-0 bundle for speed and size. The data is transient, spending at most a couple of hours on the disk before being flushed to tape. Remember that this is a *backup* - the 'real' data being elsewhere - so the increased likelihood of disk failure resulting in a failed backup is not really very important. On the other hand, having a fast enough disk system with a high capacity helps tremendously. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit University of Oxford / Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: can amanda trigger a script?
On Tuesday, 04.03.2008 at 01:26 -0800, fedora wrote: > Hi Marc/all, > > U have gave me this script to export database to other directory. > http://marc-muehlfeld.de/scripts/mybackup.sh > > If I use this script on cronjob to export databases, Amanda does not > know when will it finishes. Manual way, If let say this script finish > exported databases at 3am. Then I have to run "amdump DailySet1" > (cronjob) at 3.30am for instance. So, I always have to check and > monitor when the script finish export databases and the time depends > on the size of databases. I have to change time setting on cronjob as > well. Can Amanda trigger that script so that after exporting databases > it will run "amdump DailySet1" automatically? Well, presumably amdump is run from cron too? Why not just do: 0 3 * * * backupdb.sh && amdump DailySet1 or something similar? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit University of Oxford / Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: Query about full backups
On Tuesday, 23.01.2007 at 22:01 -0800, Yogesh Hasabnis wrote: > > If the original poster's full backup fits on to a single tape, and > > backs up in a reasonable period of time, you could just do a full > > backup every day, perhaps? > > At the moment, full backup of my data fits on a single tape, but it > may not fit, over a period of time. *nods* In that case, I'd suggest following the advice about splitting the backup job into a handful of separate disklist entries, using the appropriate exclusions, as suggested elsewhere in this thread. Cheers, Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: Query about full backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, 23.01.2007 at 01:16 -0600, Frank Smith wrote: > > Thanks for the reply. So if I only have one DLE, will the full > > backup always take place on a particular day and will only > > incremental backups be taken on the remaining days? Or will it be > > handled in some different way? > > dumpcycle is just the maximum time between fulls. Amanda often > schedules them sooner if it thinks it will level out daily tape usage. > I don't know how it handles a single DLE, as that is not really what > it was designed for. That's correct: although AMANDA is still a convenient tool to use in this context. If the original poster's full backup fits on to a single tape, and backs up in a reasonable period of time, you could just do a full backup every day, perhaps? Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFFtc4EbpQs/WlN43ARAgoTAJ94KEtTaGxUGHJBswxc8zJiwxM+dgCg4f/6 ndjziD7s1zQjV0BxcnytW3M= =PtTy -END PGP SIGNATURE-
Re: Debian packages for Amanda
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, 08.09.2006 at 15:58 -0500, Phil Howard wrote: > | For what it's worth, on a Debian Stable system, I've found that the > | AMANDA packages Just Work very nicely, especially on the clients, since > | there is basically no configuration required. > > Wouldn't I need to at least tell it where the backup server is? OK, I said "basically" :-) In the simplest scenario (assuming you're not doing any complicated authentication of client/server) is that you will need to set /etc/amandahosts on the client to contain the FQDN of the server and the backup user, e.g. ourbackupserver.our.domain backup Unless you have further preferences or requirements, that should be enough to get that client being backed up. Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFFBTBCbpQs/WlN43ARAq7yAKCV/VIGS4D4V3Doh4F45NFdrmZezACeJD43 wTIEmw137RJfwV4n+7cWmpM= =O1In -END PGP SIGNATURE-
Re: Debian packages for Amanda
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, 08.09.2006 at 01:28 -0500, Phil Howard wrote: > These packages configure the user to run Amanda as "backup". But it > seems the "backup" user also does other things. Does anyone see any > possible conflict in this? I'd say "may be used for other things", rather than "also does other things", really. To be honest, a user called backup makes more sense than a user called 'amanda' - we used to have a staff member called Amanda who existed prior to an AMANDA installation and things got ... messy. On a Debian system, the backup user is a member of the appropriate system groups to allow backups to function, i.e. a member of 'disk' For what it's worth, on a Debian Stable system, I've found that the AMANDA packages Just Work very nicely, especially on the clients, since there is basically no configuration required. Feel free to ask further related questions, because I've been using AMANDA on Debian systems for many years... Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD4DBQFFAT9mbpQs/WlN43ARAoMaAKCp62nbpm4BtIdkkJcsUY0UeH2+4gCUCs02 FgHS+8Lh8DC9ro/SlIGhYw== =qpWS -END PGP SIGNATURE-
Re: If most recent backup is not level 0, recovery fails to bring back all files when directories have been renamed
On Wednesday, 08.03.2006 at 12:05 -0500, Jon LaBadie wrote: > So, rather than use "listed-incremental" to recognize > it is a renamed directory, gnutar's behavior is to > consider then entire directory tree "changed" and > back up the entire tree. > > Reading this thread reminded me of another one where > the poster was complaining about this "feature" of > gnutar. That poster has a lot of rotating log dirs > that were quite large. They were rotated by renaming > them each night (log.2 becomes log.3, log.1 -> log.2 etc.) > Their complaint was that the data in the directory WAS > being backed up each night though it was unchanging. > > Be nice if gnutar could deal with both needs. Indeed, that very issue had occurred to me too :-) However, directory renames are fairly rare and IMO if there is an 'error' it should be "back up too much but making sure it's complete" rather than "keep the backup size small but occasionally miss something important". Of course, supporting both Would Be Nice, as you say... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: If most recent backup is not level 0, recovery fails to bring back all files when directories have been renamed
On Wednesday, 08.03.2006 at 10:27 -0500, Ian Turner wrote: > On Wednesday 08 March 2006 06:34, Dave Ewart wrote: > > In summary: when a directory is *renamed* the files underneath it are > > not considered to have changed > > This does not appear to happen with CVS tar in listed-incremental mode. > Please > try upgrading your tar and check if you still see this behaviour. > > For reference, this is the test I performed: > > $ # Build CVS tar, chdir to src/. > $ mkdir -p test/foo > $ touch test/foo/bar > $ ./tar -cvf test1.tar --listed-incremental test1.incr test > ./tar: test/foo: Directory is new > test/ > test/foo/ > test/foo/bar > $ mv test/foo test/baz > $ ./tar -cvf test2.tar --listed-incremental test1.incr test > ./tar: test/baz: Directory is new > test/ > test/baz/ > test/baz/bar OK, you've hit the nail on the head: Using the existing system tar: $ tar --version tar (GNU tar) 1.14 $ find . ./blah ./blah/a ./blah/a/foo ./blah/a/bar $ tar -cvf test1.tar --listed-incremental test1.incr blah tar: blah/a: Directory is new blah/ blah/a/ blah/a/bar blah/a/foo $ mv blah/a blah/b $ tar -cvf test1.tar --listed-incremental test1.incr blah tar: blah/b: Directory is new blah/ blah/b/ And using a rebuilt version from a more recent source: $ ~/src/tar-1.15.1/src/tar --version tar (GNU tar) 1.15.1 $ ~/src/tar-1.15.1/src/tar -cvf test1.tar --listed-incremental test1.incr blah /home/davee/src/tar-1.15.1/src/tar: blah/a: Directory is new blah/ blah/a/ blah/a/bar blah/a/foo $ mv blah/a blah/b $ ~/src/tar-1.15.1/src/tar -cvf test1.tar --listed-incremental test1.incr blah /home/davee/src/tar-1.15.1/src/tar: blah/b: Directory is new blah/ blah/b/ blah/b/bar blah/b/foo A new tar is indeed the answer it seems. Many thanks, people. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: If most recent backup is not level 0, recovery fails to bring back all files when directories have been renamed
On Wednesday, 08.03.2006 at 10:02 -0500, Gene Heskett wrote: > >This package of 'tar' is the current default in Debian/Sarge and is > >updated with various security issues without changing the version > >number, so it's not entirely clear what version is really there under > >the hood. > > Which is exactly why I get this stuff (both tar and amanda) from the > src and build my own. It Just Works(TM). :) Well, that works both ways of course. The latest source might introduce new problems, and at least distro-issued packages have been preconfigured to put the files in 'all the right places', as per the distro's usual specifications ... I'll investigate what Ian has posted about listed-incremental... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: If most recent backup is not level 0, recovery fails to bring back all files when directories have been renamed
On Wednesday, 08.03.2006 at 07:35 -0500, Gene Heskett wrote: > >On the client being backed-up: > > > >$ tar --version > > > >tar (GNU tar) 1.14 > > We believe this version of tar is borked. Please get the older > 1.13-19, 1.13-25, or the newer 1.15-1. For whatever reason, 1.14 was > only visible on gnu.org for about 5 or 6 weeks, being replaced with > 1.15-1, which for gnu.org, considering the speed they normally run at, > is instantainious. I've been running 1.15-1 since about a week after > it became available without problems. Interesting. Do you think that the behaviour I'm seeing is solely as a result of 'tar' here? Is the behaviour I describe something that you believe *should* *not* happen with AMANDA when using 'tar'? This package of 'tar' is the current default in Debian/Sarge and is updated with various security issues without changing the version number, so it's not entirely clear what version is really there under the hood. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: If most recent backup is not level 0, recovery fails to bring back all files when directories have been renamed
On Wednesday, 08.03.2006 at 11:34 +, Dave Ewart wrote: > I've just been caught out by something which is either > > (a) a limitation of AMANDA and/or tar/dump; > (b) a bug. A follow-up, prompted by a reply from Paul, indicating that I had indeed forgotten a couple of rather important bits of information! - The filesystem being discussed is ext3 - AMANDA is using 'tar' (i.e. amanda.conf states: program "GNUTAR") On the client being backed-up: $ tar --version tar (GNU tar) 1.14 Copyright (C) 2004 Free Software Foundation, Inc. ... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
If most recent backup is not level 0, recovery fails to bring back all files when directories have been renamed
I've just been caught out by something which is either (a) a limitation of AMANDA and/or tar/dump; (b) a bug. In summary: when a directory is *renamed* the files underneath it are not considered to have changed: this means that a non-level-0 backup following the directory rename only backs up the new directory entry, not the files inside the directory. This means that, if the disk fails following such a non-level-0 backup and requires a recovery, the full recovery will *not* recover the files inside the directory: the new directory will be recreated by amrecover, but will be empty. Let me demonstrate by means of a simple example: On Friday 03.03.2006, I do the following: $ ls /home/davee/stata/w total 24 -rw-r--r-- 1 davee users68 2006-02-28 16:25 Makefile -rw-r--r-- 1 davee users 479 2006-03-03 15:44 w.csv -rw-r--r-- 1 davee users 224 2006-01-19 19:21 w.do -rw-r--r-- 1 davee users 11147 2006-03-03 15:44 w.log These are files last edited on 03.03.2006 and on this night a level 0 backup took place. The index for this directory contains the directory and all its files as expected: # zgrep 'davee/stata' 20060303_0.gz /davee/stata/ /davee/stata/w/ /davee/stata/w/Makefile /davee/stata/w/w.csv /davee/stata/w/w.do /davee/stata/w/w.log On Monday 06.03.2006, no further changes are made to the files and a level 1 backup tapes place that evening. The index for that backup includes the directory entry as expected, but none of the files: # zgrep 'davee/stata' 20060306_1.gz /davee/stata/ /davee/stata/w/ On Tuesday 07.03.2006, I rename the directory 'w' to 'w2', but make no changes to the files inside the directory. The file structure now looks like this: $ mv w w2 $ ls -l /home/davee/stata/w2/ total 24 -rw-r--r-- 1 davee users68 2006-02-28 16:25 Makefile -rw-r--r-- 1 davee users 479 2006-03-03 15:44 w.csv -rw-r--r-- 1 davee users 224 2006-01-19 19:21 w.do -rw-r--r-- 1 davee users 11147 2006-03-03 15:44 w.log On the evening of 07.03.2006, a level 2 backup takes place and the index contains the new directory entry: # zgrep 'davee/stata' 20060307_2.gz /davee/stata/ /davee/stata/w2/ The files in the directory are not changed which is presumably why the files are not included in this index. (Importantly, though, the directory entry for davee/stata/w has now gone: this will matter during recovery.) SO ... (and this is big issue here) ... if the disk on which these files are stored fails at this point, a recovery DOES NOT RECOVER ALL FILES. I guessing that what happens is that the recovery process (which prompts for the tapes from 20060303, 20060306 and 20060307 in turn) does the following: - restores the contents of the level 0 backup from 20060303 which would leave the filesystem as follows: $ ls /home/davee/stata/w total 24 -rw-r--r-- 1 davee users68 2006-02-28 16:25 Makefile -rw-r--r-- 1 davee users 479 2006-03-03 15:44 w.csv -rw-r--r-- 1 davee users 224 2006-01-19 19:21 w.do -rw-r--r-- 1 davee users 11147 2006-03-03 15:44 w.log - restores the contents of the level 1 backup from 20060306 which won't make any further changes to this part of the filesystem; - restores the contents of the level 2 backup from 20060307 which introduces an emtpy directory davee/stata/w2 and REMOVES davee/stata/w because it DOESN'T EXIST ANYMORE, leaving the filesystem as follows: $ ls /home/davee/stata drwxr-xr-x 2 davee users4096 2006-03-03 15:44 w2 $ ls /home/davee/stata/w2 (nothing) Clearly the solution in this case is to perform a separate recovery of the level 0 backup and manually put the files back in place. However, in the context of a massive recovery of many thousands of files following a disk failure, events such as the one described above (which is merely a small worked example) will not be noticed. The point of my illustration is that even though one has all the appropriate tapes for the recovery process, running an amrecover and feeding in the tapes one by one will NOT RESTORE ALL FILES, if both of the following circumstances are true: - the most recent backup prior to disk failure was not a level 0 backup; - directories were renamed since the last level 0 backup. Thoughts/opinions here? BTW the AMANDA server runs Debian/Woody (2.4.2p2-4) and the client being backed up above runs Debian/Sarge AMD64 (2.4.4p3-3). Cheers, Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 signature.asc Description: Digital signature
Re: Odd permissions problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, 14.12.2005 at 16:17 +0100, Paul Bijnens wrote: > Dave Ewart wrote: > >I've just added a few entries to my disklist and am getting errors like > >the following, during amcheck: > > > >ERROR: athena: [could not access /srv/samba/netlogon > >(/srv/samba/netlogon): Permission denied] > > > >Why is this directory not visible to the AMANDA process, given that the > >AMANDA user is part of group 'disk' and that should give it access to > >those partitions? The '/root/' partition is only (technically) visible > >to the root user, yet AMANDA is able to correctly back this up. > > http://wiki.zmanda.com/index.php/Why_does_amcheck_fail_while_amdump_succeeds_%3F > > The good news is that amdump will probably work fine. > > The fact that amanda is part of group disk has no effect here: > you're doing backups of subdirectories, and thus cannot use dump, but > must use gnutar (Dump can only work on whole partitions, not on > subdirectories, at least when doing incrementals.) > > For running dumpa and accessing the device-partitions, amanda needs to > be member of the disk-group, but for running gnutar, amanda actually > needs root priviledges, which she gets by invoking gnutar with a suid > root program, which is not used by amcheck. (Note amcheck just sends a > message to amandad on the client, and it's amandad on the client that > does the check; hence making amcheck suid-root does not help either.) Ah, understood, very helpful Paul. That explains the situation sufficiently for me to be able to work around it. Thanks, Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDoEHCbpQs/WlN43ARAnN9AJ92UXOBw630FlSImG9C3fJpHhv2+ACgy4mi yACzRR4yhXZxUooRO9dOk98= =cho+ -END PGP SIGNATURE-
Odd permissions problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've just added a few entries to my disklist and am getting errors like the following, during amcheck: ERROR: athena: [could not access /srv/samba/netlogon (/srv/samba/netlogon): Permission denied] ERROR: athena: [could not access /srv/samba/install (/srv/samba/install): Permission denied] This is strange, because other entries, such as /root and /etc have been backed-up correctly for many months. This is a Debian system where AMANDA uses user 'backup', which is a member of user 'disk' - this should allow it to backup all local disks without further privileges. /srv/samba, /root and /etc are all on the same partition, /dev/sda1: # ls -l /dev/sda1 brw-rw 1 root disk 8, 1 Jun 15 18:26 /dev/sda1 Various permissions: (For working entries in disklist) # ls -ld /root drwxr-x--- 15 root root 4096 Dec 14 14:31 /root # ls -ld /etc drwxr-xr-x 85 root root 4096 Dec 14 14:38 /etc (For non-working entries in disklist) # ls -ld /srv drwxr-xr-x 3 root root 4096 Nov 28 10:39 /srv # ls -ld /srv/samba drwxr-s--- 10 root everyone 4096 Nov 21 10:38 /srv/samba # ls -ld /srv/samba/install/ drwxr-s--- 5 root everyone 4096 Nov 15 10:01 /srv/samba/install/ # ls -ld /srv/samba/netlogon/ drwxr-s--- 3 root everyone 4096 Dec 14 09:08 /srv/samba/netlogon/ If I make '/srv/samba' chmod-ed to 755, then the permissions errors go away. HOWEVER, I don't want to do that, since there are good reasons for that directory having the permissions it does. Why is this directory not visible to the AMANDA process, given that the AMANDA user is part of group 'disk' and that should give it access to those partitions? The '/root/' partition is only (technically) visible to the root user, yet AMANDA is able to correctly back this up. Ideas/hints? Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDoDHtbpQs/WlN43ARArqiAKDlnbEHeiERhCJ4RZ1K6pfA+T61/QCgmo4e EeFlnVElcIw6MEjUNkrMVI0= =gTQG -END PGP SIGNATURE-
Re: Tapetype definition for Quantum DLT-V4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday, 29.11.2005 at 11:09 +, Dave Ewart wrote:
> Hello all,
>
> Does anyone have a tapetype definition for a Quantum DLT-V4? This is a
> 160GB native capacity drive and is connected to an Adaptec 29160
> Ultra160 SCSI adapter.
>
> I would like to encourage people to add their tapetype definitions to
> http://wiki.zmanda.com/index.php/Tapetype_definitions - this will be a
> very useful resource.
Well, I ran the 'tapetype' program and came up with the following
definition, which I've added to the Wiki too, for reference:
define tapetype Quantum-DLT-V4 {
comment "Quantum-DLT-V4 on Adaptec 29160"
length 157284 mbytes
filemark 0 kbytes
speed 9936 kps
}
Cheers,
Dave.
- --
Dave Ewart
[EMAIL PROTECTED]
Computing Manager, Cancer Epidemiology Unit
Cancer Research UK / Oxford University
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc
N 51.7518, W 1.2016
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDjssObpQs/WlN43ARAsVkAJ44ETN0geo/SSc24MA7ymwZiGvC4QCgrDjG
Jatxq+1VdaklRJ+1/Gby4Vs=
=DPbD
-END PGP SIGNATURE-
Tapetype definition for Quantum DLT-V4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, Does anyone have a tapetype definition for a Quantum DLT-V4? This is a 160GB native capacity drive and is connected to an Adaptec 29160 Ultra160 SCSI adapter. I would like to encourage people to add their tapetype definitions to http://wiki.zmanda.com/index.php/Tapetype_definitions - this will be a very useful resource. Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDjDbzbpQs/WlN43ARAj9ZAKCEcbj+jjaltmmf1zvZoHPMjL9DNACgl7Fw KTsKpjoiOkXoztOmHfy6v2s= =qa2v -END PGP SIGNATURE-
Re: Backing up mail spools (was Re: How do I deal with STRANGE backups ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, 23.08.2005 at 09:23 -0400, Jon LaBadie wrote: > > 1. Just put up with it: spools that are changing will result in a > > backup which is probably not of any use once in a while. This is > > probably fine, unless there is a large amount of mail coming in at > > the time the backup runs; > > Just one point on this. I don't think you get a backup that is > useless. It is my understanding that the "backup" is still ok; the > problem is that specific files within the backup are questionable. Yes, I understand that: I should have said that the backup is "probably not of any use FOR THAT FILE WHICH CHANGES". Having said that, it might be, or you could probably extract parts of it ... Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDCyUEbpQs/WlN43ARAl4nAKCJ9fqSqfJYCa+bREYYu5gRXpg/BwCfckYb /u8vT+hTooZwIrwC94X1X4w= =A74G -END PGP SIGNATURE-
Re: Backing up mail spools (was Re: How do I deal with STRANGE backups ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, 23.08.2005 at 11:01 +0200, Paul Bijnens wrote: > >3. Copy in a robust fashion from the mail spools to a temporary > >location prior to the backup job, so that these copies of the spools > >will not change; then backup the copies rather than the 'live' > >spools. The "robust fashion" would work in a similar way to how > >locking mail spools operates when appending/deleting messages. > > I use filesystem snapshots. Taking a snapshot is only matter of > seconds. I make a snapshot a few minutes before the amanda backup > starts. Amanda then makes a backup of that snapshot instead > > Your OS has to support is however. Solaris >2.8 (2.8 plain needs > patches) can do it. Linux with lvm1 can do it too; Linux with lvm2 is > not yet stable enough for doing snapshots. (I have lvm2 snapshots > working on one system without problems, but on other systems it makes > the computer crash; maybe related to amount of memory and/or system > load: the system where it does work has lots of RAM, and is very quiet > in the night.) > > Mail me for the scripts to create a snapshot if you're interested. The server in question is a fairly generic Debian/Sarge mail server, RAID setup for disks, 2.6 kernel. And /var/mail is on its own ext3 partition. You mention that it works with LVM. Do snapshots *require* LVM? Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDCvA5bpQs/WlN43ARAv4cAKCmduKWAwWn4ju6f3Z6Js4s31kpKACfUA9G px5PyDzKKlRTDoy6JmZwmcQ= =MeB5 -END PGP SIGNATURE-
Backing up mail spools (was Re: How do I deal with STRANGE backups ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday, 22.08.2005 at 22:53 -0400, Jason 'XenoPhage' Frisvold wrote: > [ ... some are new mail messages coming in ... ] I've often wondered about this. I back up the mail spools in /var/mail of the appropriate server and occasionally get a 'STRANGE' from it because one of the spools changes during the course of the backup job. What is considered the Correct Way to handle backing up files which are so dynamic? Our mail spools are pretty quiet at the time the backup runs, but some of you out there must have more traffic than us ... My thoughts: 1. Just put up with it: spools that are changing will result in a backup which is probably not of any use once in a while. This is probably fine, unless there is a large amount of mail coming in at the time the backup runs; 2. Make a policy decision not to backup mail spools at all. There are often reasons for making such a policy, although it's not something that we do; 3. Copy in a robust fashion from the mail spools to a temporary location prior to the backup job, so that these copies of the spools will not change; then backup the copies rather than the 'live' spools. The "robust fashion" would work in a similar way to how locking mail spools operates when appending/deleting messages. If option #3, has anyone actually done that? How? Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDCttDbpQs/WlN43ARAuFeAKDnef5GW2pZ/08qHnr1l1qYJKYhtACg0gkV 14YTwNMAJYmalmCvByQZopE= =kvg8 -END PGP SIGNATURE-
Re: Duration Of Backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, 17.08.2005 at 09:13 -0400, Mangala Gunadasa wrote: > We have been using amanda for many years. Our capacity had grown and > currently we are backing up 60 file systems across 12 servers. The > backup takes 9hrs to finish. We have tried to make it more efficient > by changing the parameters "interface", and "net usage" of the > amanda.conf and did not succeed( Probably those parameters do not > matter). We would like to perform Full backup every Day to a SDLT Tape > drive. We will be adding 2 IBM P570's and we are concerned about the > duration of the backup. Can we find how the big sites manage this type > of situation?. I appreciate any comments on this subject. To figure out a way to reduce the run time of the backups, you need to work out whether you are hitting a network bandwidth limit, a hardware limitation or something else. Some ideas: 1. Relaxing your condition of a full backup every day would reduce your backup duration, since each day AMANDA would be doing full backups of some systems and level 1 backups of others. If your filesystems are fairly static, this may make sense. I obviously don't know your circumstances, but do you *really* need a full backup of *everything* every day? If you have a largely static setup, then insisting on a full backup only once every two days may reduce your run time from 9 hours down to 5 or 6 hours. 2. Upgrade your network infrastructure or your AMANDA server. For example, if you're running 100megabit, can you switch to gigabit? Can you give your AMANDA server a faster holding disk? 3. Get another tape drive and run backups in parallel. Note however, that this will not reduce run time if your backup job is network-bandwidth-bound. 4. Check your compression configuration parameters. Are dumps being compressed on the client, or the server, or on the tape drive? For example, are slow clients being made to compress stuff themselves? Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDAzu1bpQs/WlN43ARAtLiAJ95fwMkh+awuET9OGw/7I7QfohiugCeNRXO ccD6x1zIA5lMf2y9J7FXW1I= =uaa+ -END PGP SIGNATURE-
Re: ssh keys only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, 19.07.2005 at 09:06 -0500, Vicki Stanfield wrote: > Most of our servers are accessible only via ssh with a root key. Does > amanda work in such a setup or does the amanda user have to have > regular login access? One of my coworkers changed one of our servers > to only accept logins via ssh and now amanda doesn't seem to be able > to get there and we get the following message: > > WARNING: /host/: selfcheck request timed out. Host down? > > I suspect that amanda simply doesn't like not being able to log in. Is > this accurate? AMANDA clients should have an entry in /etc/inetd.conf (or somewhere under /etc/xinetd.d depending on distro). This means that the client is listening on the amanda port (typically 10080) and will respond to connections appropriately. The trick is to ensure that /etc/amandahosts contains the list of usernames and hosts which are allowed to connect. This doesn't depend on ssh or login sessions at all. Note that /etc/amandahosts is the name of the file under Debian - in general the file is called .amandahosts and appears in the home directory of the amanda user (usually 'backup'). Debian achieves this using symlinks. Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFC3Qo+bpQs/WlN43ARArUIAJ942oV5xS8dCIQeR6TCf+SApH6suACgrIfx VRW3Dty2CpunuxZhyUSAEJQ= =kgAG -END PGP SIGNATURE-
Backup through firewall: --with-portrange=xxx,yyy - reconfigure client/server/both?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am trying to backup a client which resides behind a firewall. As per the notes at http://amanda.sourceforge.net/fom-serve/cache/139.html I see that AMANDA needs to be rebuilt with options for - --with-portrange=xxx,yyy and --with-udpportrange=xxx,yyy My question is, does AMANDA need to be rebuilt with those options (a) on the server; (b) on the client; (c) on both the client and the server? Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Cancer Epidemiology Unit Cancer Research UK / Oxford University PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 N 51.7518, W 1.2016 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCrrlGbpQs/WlN43ARAtcjAJ9Kl2OcreXzuCwkziEyvdvp4pOWEACZAd/1 oGQ4Zx5FyG9gyMb/jlx2z3Q= =x16Q -END PGP SIGNATURE-
Re: Why include parent directory in disklist?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, 06.04.2005 at 10:03 -0400, Vicki Stanfield wrote: > >>I am still trying to understand and improve my inherited amanda > >>configuration. I notice that in the disklist, there are parent > >>directories listed before their children. Here is an example: > >> > >>myhost/ comp-low-tar > >>myhost/usrcomp-low-tar > >>myhost/varcomp-med-tar > >>myhost/net/myhost/home comp-med-tar > > > >Normally, a single entry in the disklist with have it subdirectories > >backed up, as long as that stays on a single disk partition. So, if you > >have / and /usr on different partitions, you need to list them > >separately. If they're on the same partition, you don't need to list > >them again. > > Thanks Dave, > So then if /net/mysystem/home is on the same partition as > /net/mysystem/username, is /net/mysystem/username being backed up twice. > It sounds to me like it is. Erm, not sure, because /net/mysystem/username is not mentioned in your disklist. From the above entries, /net/mysystem/username lies under / and would thus be backed up. Perhaps it would be useful if you show us the partition layout on your system. What output does the command 'mount' return? Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCU/s+bpQs/WlN43ARAs9VAJ0eagWcZlA9yyhIV9yEouyl/ks1kACeK9Gx ZQkrLgq4s8nfm+BPOASjBGQ= =YRAk -END PGP SIGNATURE-
Re: Why include parent directory in disklist?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, 06.04.2005 at 09:34 -0400, Vicki Stanfield wrote: > I am still trying to understand and improve my inherited amanda > configuration. I notice that in the disklist, there are parent > directories listed before their children. Here is an example: > > myhost/ comp-low-tar > myhost/usrcomp-low-tar > myhost/varcomp-med-tar > myhost/net/myhost/home comp-med-tar Normally, a single entry in the disklist with have it subdirectories backed up, as long as that stays on a single disk partition. So, if you have / and /usr on different partitions, you need to list them separately. If they're on the same partition, you don't need to list them again. Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCU/YjbpQs/WlN43ARApz+AJ9qFGybKrhbj+N2N8PE7Dft8rlj7QCfdY9t zVIBer9HcWCjSsGH6dE+VbY= =sbsL -END PGP SIGNATURE-
Re: Problems with HP SureStore VS80e (DLT1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, 25.11.2004 at 13:57 +, Martin Hepworth wrote: > >>The situation quickly became worse and at some point the tape drive > >>refused to eject the tape cartridge. We called the HP support and > >>they replaced the drive without problems. With the new drive, the > >>nightly backup again started to work fine. > >> > >>After about 2 weeks, the same errors occured again. The nightly > >>backup runs began to fail up to the point where the drive refused to > >>eject the cartridge. So, HP replaced the drive again and we started > >>to use our third drive in about 7 months of usage. > > > >Interesting. Same thing happened to us with a Tandberg DLT1 vs80 > >drive, which I believe is fundamentally the same as the HP model. > > > >Same symptoms as the above, but we've only had one 'dead' drive. I > >assumed it was Just One Of Those Things. The first drive lasted for > >about 12 months and the second has been going fine for about 10 > >months so far. > > > >Dave. > > > >- -- > >Dave Ewart > > And here - seems to be heat related. Of the drives that have died > (2xDLT1's and 1x VS80 all HP), have died on hot days in not temp > controlled rooms. Hmmm - curious. My notes show that our drive keeled over in May (not 10 months ago, as I said above), although it did survive the hot summer of 2003 :-) Perhaps I should move ours into the air-conditioned room ... Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBpgqQbpQs/WlN43ARAr7aAJ4tgWfkz8NF1FuPvzdNblvwlRoRBQCg2Riz Ee+m536p36BvqAkDUkPdm+A= =8Kio -END PGP SIGNATURE-
Re: Problems with HP SureStore VS80e (DLT1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, 25.11.2004 at 14:22 +0100, Andreas Haumer wrote: > [...] > > The situation quickly became worse and at some point the tape drive > refused to eject the tape cartridge. We called the HP support and they > replaced the drive without problems. With the new drive, the nightly > backup again started to work fine. > > After about 2 weeks, the same errors occured again. The nightly backup > runs began to fail up to the point where the drive refused to eject > the cartridge. So, HP replaced the drive again and we started to use > our third drive in about 7 months of usage. > > [...] Interesting. Same thing happened to us with a Tandberg DLT1 vs80 drive, which I believe is fundamentally the same as the HP model. Same symptoms as the above, but we've only had one 'dead' drive. I assumed it was Just One Of Those Things. The first drive lasted for about 12 months and the second has been going fine for about 10 months so far. Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBpeGhbpQs/WlN43ARAqHXAKD24gjgFLNIOksgERPKP66N4GyUTgCguxOw SSl+zAOfI9bi5e1TmHwOLH0= =ghHC -END PGP SIGNATURE-
Re: [OT] cron.d entries for Amanda
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tuesday, 16.11.2004 at 12:13 +, Gavin Henry wrote:
> Dear guys,
>
> THis simple error is doing my head in, so I'm going to ask and risk
> looking like a fool, but anyway...
>
> We normally install our Amanda crons in /etc/cron.d/suretec on client
> servers (we are using amanda and custom scripts to backup
> http://www.eems.co.uk - a very high profile 2 x SUSE Ent 8 servers).
>
> I keep getting e-mails from crond with errors, e.g.
>
>
> /bin/sh: line 1: /usr/bin/find /u01/app/oracle/archdest2/* -mtime +7 -exec
> rm{}\;:
> No such file or directory
>
> AND
>
> /bin/sh: line 1: /opt/suretec/sbin/amcheck -m learnit-dbserv-db-warm: No
> such file
> or directory
>
>
> My cron.d entries look like:
>
> 0 3 * * 1-5 amanda /opt/suretec/sbin/amcheck -m blah.blah
>
>
> I'm pretty so amcheck is in her path and anyway, I have defined the
> absolute path, also cron.d entries can take arguments.
>
>
> What stupid typo have I made.
>
> P.S> I know this makes me look quite unprofessional, but I'm sure we've
> all hit some kind of stupid brick wall. "Can't see for looking", as the
> saying goes here in Scotland.
Do you actually have 'find' where you say it is? (/usr/bin/find)
Dave.
- --
Dave Ewart
[EMAIL PROTECTED]
Computing Manager, Epidemiology Unit, Oxford
Cancer Research UK
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBmfOwbpQs/WlN43ARArLHAJ0YeVw0iT2IZ/l5MbmMn8IHwcG/UwCgkA++
13NEeJ9B/hWE4NPPZ0KiMQ0=
=uRnG
-END PGP SIGNATURE-
Re: Need help with backup plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, 31.08.2004 at 10:42 -0400, Joe Konecny wrote: > Right now I back up my Netware server with Arcserve to a single tape. > I have 10 tapes. The system is set up to accept any tape and run a > full backup. What we do is keep the tapes in rotation and if someone > forgets to bring a tape back from off site it is no big deal we just > use the next one. Arcserve assigns each tape a new ID when it uses > it. We write the date of the backup on the case of each tape. If a > restore is needed we figure out what date we want and insert the tape. > Arcserve will tell us the tape ID and then we can restore from that > session. Now I'm switching to FreeBSD and have a working Amanda > install with 10 tapes. I have yet to configure the cycle, etc... as > I'm not sure how to make it work like Arcserve did. Can Amanda be > made to work like that? Won't comment specifically for your case but most questions of "Can Amanda be made to work like that?" are normally not the right thing to ask. Find out how AMANDA actually *does* it and then fit in with its way of doing things. AMANDA is good at scheduling backups. Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBNI/fbpQs/WlN43ARAlVzAKC70NcgufKVQtbeK4DLGacf0AMzYgCaA8Gi xZjFI6PMHi4RKbfyZMmf19g= =Qo1J -END PGP SIGNATURE-
Out-of-office replies?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear AMANDA users, Recent posts to the AMANDA users list have attracted a lot of "out of office" replies. I also used to send "please don't autoreply to mailing list" messages back to these subscribers. However, looking at the headers of a typical amanda-users post, there is *nothing* there to help autoreply/vacation software identify it as a mailing list post. Can some list admin please add "Precedence: list" or something to the message headers? Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBNICwbpQs/WlN43ARAnrrAJoDlUyxFafCmKGvxSi0B1aKnuZ9+gCeMweD gz7j+eMdSGjVqpKlZRFAYho= =akj7 -END PGP SIGNATURE-
Re: Labeling tapes with "day of the week", is not a good practice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, 31.08.2004 at 13:55 +0100, Ranveer Attalia wrote: > All of our Daily and Weekly tapes are labelled with the day of the > week. Is there any easy way that we can revert back to the Amanda way > of labelling the tapes? If it is possible and we can revert, would we > still beable to restore off the "day of the week" tapes that we have > up until now if we ever need to? You can migrate your currently named tapes from your 'daily' names to some other, 'non-daily' names. I have done this! You do this by gradually changing the names of tapes as you go through your normal backup cycle. We have 20 tapes and it took 20 days to make all these changes. For instance, say you want to change from Blah-Monday-1, Blah-Tuesday-1 etc. to Blah-001, Blah-002 etc. You do this: 1. Change the regular expression in amanda.conf to recognize *both* the old and the new tape names. This is the 'trick' to making this work. 2. When a tape is due for re-use, just before use, you relabel it according to the new scheme. You then 'amrmtape' the old name. 3. Do this each day for your entire tapecycle. After $TAPECYCLE days, all your tapes will be labelled with the new scheme and you can change the label regexp in amanda.conf to just recognize the new labels. At all times, you are able to restore for any tape, as normal, whether named new or old. Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBNHk0bpQs/WlN43ARAgJZAJ9m4HIzVqJ3bD/zva5E9Yy8MpxS+gCg8Yyy 25RThkVU8KD6sVDe/FRvZAc= =0DDO -END PGP SIGNATURE-
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, 28.07.2004 at 13:34 -0400, Andrew Hall wrote: > > Hi all, > > > > Has this been discussed before? > > > > I was thinking of using a encrypted filesystems for the tmp storage, > > then dumping that to tape? > > I set this up a few years back and it rocked! > > http://security.uchicago.edu/tools/gpg-amanda/ Just make sure that you keep your GPG keys backed up *separately* :-) Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCLNabpQs/WlN43ARAiR2AKDQ+aEXUhSUST+/rfsWcxxJrjfpMgCfSaQh j4jj01uLzL50on0Vt0eWJuM= =wZor -END PGP SIGNATURE-
Re: Joe Harpole/St Louis/IBM is out of the office.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, 02.06.2004 at 16:13 +0100, Tony van der Hoff wrote: > > I will be out of the office starting 06/02/2004 and will not return > > until 06/03/2004. > > > > I'll be out of the office Monday & Tuesday for Mom's Cardiac Cath > > test and possible surgery. > > Just what we all wanted to know... I have sent him a (reasonably) polite, but "to-the-point" message about this, asking him to reconfigure his (broken) auto-reply software. Dave. - -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAvfBubpQs/WlN43ARArUmAKC+lltShk/aH+o6QL/3XrLql2cD2wCg3cBM Q8NsPfh3bCChaR2zlNwzkaQ= =WAhP -END PGP SIGNATURE-
Re: Tape error - how 'bad' is this?
On Tuesday, 11.05.2004 at 13:24 -0400, Gene Heskett wrote: > Dave, when was the last time a cleaning tape was cycled thru that > drive? Happens pretty regularly ... and the drive is being prepared for a warranty repair. Now have a replacement drive in use. Thanks everyone for comments/suggstions, Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Tape error - how 'bad' is this?
On Tuesday, 11.05.2004 at 22:00 +1000, Phil Homewood wrote: > If it's anything like a DLT4000 drive, Sense4/ASC15/ASCQ1 is "Hardware > error: Random Mechanical Positioning Error" and Sense3/ASC15/ASC2 is > "Medium error: Position error detected by read of medium". > > Or so sayeth my DLT4000 manual, which has also proven accurate for > DLT1 sense codes. Sounds like a hardware problem. :-( Hmm, I'm beginning to believe that's the case. I've ordered a replacement drive so that we can have that up and running quickly. Will hopefully also be able to get this one repaired, but no-one can give me a guaranteed repair schedule that doesn't cost more than a new drive! Thanks for your help ... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Tape error - how 'bad' is this?
On Tuesday, 11.05.2004 at 11:24 +0200, Stefan G. Weichinger wrote: > >>> [...] kernel: ASC=15 ASCQ= 2 > >>> [...] kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x16 0x00 0x00 > >>> +0x4f 0xc8 0x15 0x02 0x00 0x00 0x00 0x00 0x82 0x01 0x55 0x00 > >>> 0x00 0x25 0x3b 0x00 0x96 0x32 0x50 0x00 > >>> [...] kernel: st0: Error on write filemark. > > DE> What looks like the problem here? The drive itself? The SCSI > DE> controller? We have a HP DLT-40 drive on an Adaptec 29160 controller. > DE> There have been no configuration changes to the server. > > Sounds like a SCSI-problem to me. > > Try to communicate with the drive outside of AMANDA. > > What does > > mt -f /dev/st0 status blackhole: ~ # mt -f /dev/st0 status drive type = Generic SCSI-2 tape drive status = 1073741824 sense key error = 0 residue count = 0 file number = 0 block number = 0 Tape block size 0 bytes. Density code 0x40 (unknown). Soft error count since last status=0 General status bits on (4101): BOT ONLINE IM_REP_EN Anything odd there? > tell you? (You did not mention the OS, but the message points to > Linux). Yeah, sorry - it's running a vanilla Debian Woody installation. > Check cabling, sometimes it is enough to just reconnect everything > (after shutdown ;-) ). > > I am not sure if this could also happen with a bad tape ... as it > tells you the device is failing to write a filemark. > > Maybe try another tape, but as you said that this happens since 2 days > (and 2 tapes, I assume, or is it still the same?) the scsi-system > seems to be responsible. Appears to have affected two tapes now ... so I'm guessing it's not the tapes. Will try playing with the connectors and perhaps reseat the controller card, that sort of thing. This system can afford downtime, since it doesn't do anything other than run the backups overnight ... Thanks for the suggestions ... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Tape error - how 'bad' is this?
Hi, Many months of happy activity and then suddenly, last two nights, the AMANDA job has failed to finish properly - the error in the AMANDA report says: >> These dumps were to tape Daily-014. >> *** A TAPE ERROR OCCURRED: [[writing file: Input/output error]]. >> Some dumps may have been left in the holding disk. >> Run amflush to flush them to tape. >> The next tape Amanda expects to use is: Daily-015. >> >> FAILURE AND STRANGE DUMP SUMMARY: >> halcyon/root lev 0 FAILED [out of tape] >> >> [...] >> >> STATISTICS: >> Total Full Daily >> >> Estimate Time (hrs:min)0:45 >> Run Time (hrs:min) 8:09 >> Dump Time (hrs:min)8:15 0:25 7:50 >> Output Size (meg) 10606.2 1315.9 9290.3 >> Original Size (meg) 22351.7 2115.120236.6 >> Avg Compressed Size (%)47.5 62.2 45.9 (level:#disks ...) >> Filesystems Dumped 54 28 26 (1:21 2:4 4:1) >> Avg Dump Rate (k/s) 365.7 888.3 337.6 >> >> Tape Time (hrs:min)0:14 0:08 0:06 >> Tape Size (meg) 612.8 332.6 280.2 >> Tape Used (%) 1.71.00.7 (level:#disks ...) >> Filesystems Taped36 26 10 (1:10) >> Avg Tp Write Rate (k/s) 745.4 745.0 745.9 >> >> [...] >> >> taper: tape Daily-014 kb 653792 fm 37 writing file: Input/output error >>driver: going into degraded mode because of tape error. I notice it mentions "out of tape" above - that's definitely wrong. There's certainly plenty of room for all the dumps. And in the kernel logs for the AMANDA server: >> [...] kernel: st0: Error with sense data: Info fld=0x8000, Deferred st09:00: sns >> += f1 4 >> [...] kernel: ASC=15 ASCQ= 1 >> [...] kernel: Raw sense data:0xf1 0x00 0x04 0x00 0x00 0x80 0x00 0x16 0x00 0x00 >> +0x4f 0xc8 0x15 0x01 0x00 0x00 0x00 0x00 0x82 0x01 0x55 0x00 0x00 0x25 0x3b 0x00 >> 0x96 0x32 0x50 0x00 >> [...] kernel: st0: Error with sense data: Info fld=0x1, Current st09:00: sns = >> +f0 3 >> [...] kernel: ASC=15 ASCQ= 2 >> [...] kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x16 0x00 0x00 >> +0x4f 0xc8 0x15 0x02 0x00 0x00 0x00 0x00 0x82 0x01 0x55 0x00 0x00 0x25 0x3b 0x00 >> 0x96 0x32 0x50 0x00 >> [...] kernel: st0: Error on write filemark. >> [...] kernel: st0: Error with sense data: Info fld=0x8000, Deferred st09:00: sns >> += f1 4 >> [...] kernel: ASC=15 ASCQ= 1 >> [...] kernel: Raw sense data:0xf1 0x00 0x04 0x00 0x00 0x80 0x00 0x16 0x00 0x00 >> +0x4f 0xc8 0x15 0x01 0x00 0x00 0x00 0x00 0x82 0x01 0x55 0x00 0x00 0x25 0x3b 0x00 >> 0x96 0x32 0x50 0x00 >> [...] kernel: st0: Error with sense data: Info fld=0x1, Current st09:00: sns = >> +f0 3 >> [...] kernel: ASC=15 ASCQ= 2 >> [...] kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x16 0x00 0x00 >> +0x4f 0xc8 0x15 0x02 0x00 0x00 0x00 0x00 0x82 0x01 0x55 0x00 0x00 0x25 0x3b 0x00 >> 0x96 0x32 0x50 0x00 >> [...] kernel: st0: Error with sense data: Info fld=0x8000, Deferred st09:00: sns >> += f1 4 >> [...] kernel: ASC=15 ASCQ= 1 >> [...] kernel: Raw sense data:0xf1 0x00 0x04 0x00 0x00 0x80 0x00 0x16 0x00 0x00 >> +0x4f 0xc8 0x15 0x01 0x00 0x00 0x00 0x00 0x82 0x01 0x55 0x00 0x00 0x25 0x3b 0x00 >> 0x96 0x32 0x50 0x00 >> [...] kernel: st0: Error with sense data: Info fld=0x1, Current st09:00: sns = >> +f0 3 >> [...] kernel: ASC=15 ASCQ= 2 >> [...] kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0x00 0x01 0x16 0x00 0x00 >> +0x4f 0xc8 0x15 0x02 0x00 0x00 0x00 0x00 0x82 0x01 0x55 0x00 0x00 0x25 0x3b 0x00 >> 0x96 0x32 0x50 0x00 >> [...] kernel: st0: Error on write filemark. What looks like the problem here? The drive itself? The SCSI controller? We have a HP DLT-40 drive on an Adaptec 29160 controller. There have been no configuration changes to the server. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Novell and Amanda
On Thursday, 29.04.2004 at 15:36 +0100, Gavin Henry wrote: > >Out of interest, why is your existing backup software insufficient > >for your purposes? > > The admin doesn't know how to use it [...] Fair enough :-) Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Novell and Amanda
On Thursday, 29.04.2004 at 15:11 +0100, Gavin Henry wrote:
> >We have a Debian box which mounts our Netware server's disks as ncpfs
> >filesystems - and we add these mount points to the AMANDA disklist.
>
> This is what I had in mind. We have 6 Windows servers; AD, SQL,
> Citrix/E-mail/Exchange and 3 other windows 98 call logger machines and
> one last one for the PABX. 1 Netware 4 box. 1 AIX 4.0.
>
> I could get an old box, not sure what spec, install Fedora on it (my
> choice) and hang the HP Ultrium multitape drive off it and back them
> all up.
Basically, there should be no problem doing that. An AMANDA server
doesn't really need to be anything special - a faster machine should
give you faster throughput to the tapes, of course, until you reach the
limit of the drives.
Also, get a LARGE holding disk - or possibly more than one. If you are
planning to backup up to 200GB, you will benefit from having at least
that much as holding disk, ideally many times that space. A couple of
cheap IDE disks would be best.
> The tapes are 200GB each. I could use the novelclient to log
> as admin and then mess with the AIX one too. I take it the windows
> boxes would be via their shares? How would samba be configured for
> this?
You backup via Samba yes - haven't personally had to do this ("If it's
on your Windows PC it doesn't get backed up." is my policy) so I'll let
someone else answer that.
> >If you have any more questions, knowing a bit more about what you have
> >in mind would be helpful.
>
> I am not the admin here, but he is really struggling with Back falling
> all the time.
>
>
> Hardware:
> HP Ultrium 1 LTO StorageWorks 1/8 autoloader with C7971A 200GB Tapes
Don't know this tape drive, but if it is supported by your chosen
operating system and by AMANDA, then that won't be a problem.
> Current Software:
> BrightStor ARCServe backup Version 9 (Build 2020)
Out of interest, why is your existing backup software insufficient for
your purposes?
Dave.
--
Dave Ewart
[EMAIL PROTECTED]
Computing Manager, Epidemiology Unit, Oxford
Cancer Research UK
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Novell and Amanda
Gavin Henry wrote: > Is it possible to backup Novell 4 via Amanda via a HP Ultra multitape > drive? Assuming you aren't talking about actually running AMANDA on the Novell server itself, you should be able to do something here. We have a Debian box which mounts our Netware server's disks as ncpfs filesystems - and we add these mount points to the AMANDA disklist. Works fine. Strangely, when we had the same config on a Red Hat box, although the backups would work OK, AMANDA (or tar or whatever) couldn't figure out how to do level 1 and higher backups (something to do with the file modification dates visible over ncpfs). If you have any more questions, knowing a bit more about what you have in mind would be helpful. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Replacing a tape....
On Thursday, 12.02.2004 at 08:26 -0800, Pro-Fit wrote: > Can someone please tell me in the simplest terms how I can replace a > corrupt tape in Amanda? > > I have a tape - weeklyset0302 -which is faulty. How do I get a new > tape in it's place if I can label it with the same label?? I need to > flush a backup to this tape in order to get my backups back on > schedule. I believe all you need to do is force a label on to the new tape - amlabel with the '-f' option should do it. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Changing Amanda server
On Wednesday, 11.02.2004 at 21:42 -0600, Frank Smith wrote: > > I haven't seen this question in the list or archives. How do I > > gracefully move amanda databases from one (Irix) server to a new one > > (Linux). I expect to handle the build and configuration on the new > > host. I'll be moving our Exabyte jukebox from old to new host. > > > > Once the hardware and build dances are done, can I just (translate > > and?) move some files from the old server to the new one, keeping > > the same catalogs etc to access our current inventory of backups? > > I've never moved between platforms, but I did move our server from one > Linux host to another. As I recall, all I had to do was copy over the > config directories to the new server and update .amandahosts on all > the clients (both were built with almost identical configs). All the > files (indexes, tapelists, configs,etc.) are just text files, so you > shouldn't have a problem (unless you were using 'localhost'). I would > be sure to verify that you can read the old tapes properly on the new > server in case there is some byteorder issue. Don't forget that if > the OS of the server and client are different, if you used dump to > backup then you need to restore onto a client that is the same OS as > the original filesystem. Similar experience here, too. Not a problem moving from RH Linux 7.3 to Debian Woody ... just copy across all the /var/log/amanda and /etc/amanda stuff. Our only slight issue was the 'localhost' one given above. However, anything needing to be *restored* to the host that was previously called 'localhost' can of course just be restored to the 'new' localhost and then copied across to the correct machine. I guess your *real* question is whether *Irix* to Linux will be an issue. Generally, though, it seems that a move from system to system should not be a big deal ... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: amrmtape question
On Thursday, 05.02.2004 at 10:05 -0500, Kin-Ho Kwan wrote: > Hi, > > Is it sufficient enough to just run "amrmtape -n conf TAPE001" so that > Amanda will not use this tape for backup? > > I try to run "amrmtape -n conf TAPE001", but Amanda still use that > tape to backup stuff. Is there any other command I need to run to > remove the Amanda label? Reading TFM, I see: -n Generate new tapelist and database files with label removed, but leave them in /tmp and do not update the original copies. I suggest dropping the '-n' ... :-) Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: suggestions for a backup scheme?
On Thursday, 22.01.2004 at 16:19 +0100, Eugen Leitl wrote: > So I'm going to use a tape/day, labeled DailyMachineWeekdayNumber, > e.g. u03Monday01,u03Monday02, u03Monday03, u03Monday04. Is it possible > to promote a full dump, say, Monday for u01, Tuesday for u02, etc., > and store diffs relative to it? Without answering your other questions, can I say that using 'day of the week' names for your tapes is probably a bad idea. If you get out of sequence, it'll be confusing. We currently have day-of-the-week tapes, but in setting up a new rotation scheme on a new server shortly, the plan will NOT to do that. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: How to fix annoying break in tape sequence?
On Monday, 01.12.2003 at 20:11 +0100, Gerhard den Hollander wrote: > > We have a four-week, five days per week cycle: > > Good :) > > > These twenty tapes are named OurName-A-Mon, OurName-A-Tue, ..., > > OurName-A-Fri, OurName-B-Mon, ..., OurName-D-Fri (in other words, > > the letters A, B, C, D refer to weeks in the four-week cycle): > > Bad idea. > > Why not simpl;y name the tapes YourName001 -> YourName020 Yes, I know you're right. To be honest, that is something I'm considering changing. I have a method sorted out to do gradually rename all the tapes. > And then every day you have a cronjob (say at 15:00 and at 16:00) that > does an amcheck -m YourConfig We do that anyway, just in case we've forgotten to load the tape. "Knowing" what the next tape is, is no more/less easy regardless of whether you use YourName001 -> YourName020, or OurName-A-Mon etc. > When you come to Xmas, you will either have to go to work to replace > the tapes, or have to live with a shifted week. Actually, this one's easy, because we have a clean two-week shutdown at Christmas. :-) Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: How to fix annoying break in tape sequence?
On Monday, 01.12.2003 at 12:51 -0500, Brian Cuttler wrote: > > Remember to set a calendar reminder to reactivate it. > > We always run amcheck -m from cron - if the tapes are out of sequence > we notice (also someone reads the amdump output which lists both > current and next tapes). Already doing both of the above :-) Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: How to fix annoying break in tape sequence?
On Monday, 01.12.2003 at 11:32 -0500, Jon LaBadie wrote: > I think if you reduce your tapecycle, say to 15, then it will use any > tape used less recently than the last 15. You can still cycle 20 > tapes and it will ask for them in sequence. I think it may still ask > for the missed tape until it is finally used. Or you can "no reuse" > it until it is due. Since you will still have more than the "15" > tapecycle tapes in use it will not ask for a "new tape". Sounds good - I've done: (i) Set OurName-B-Fri to be 'no-reuse'; (ii) Reduced tapecycle to 18 (just being cautious!); and amcheck at least now asks for the tape I want to use ... Cheers, Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: How to fix annoying break in tape sequence?
On Monday, 01.12.2003 at 16:32 +, Tom Brown wrote: > $amflush config There's nothing to flush ... > or alter the config/tapelist file so that the required OurName-C-Mon > is at the bottom (although this is less desirable) Are you sure? I have read that altering tapelist has no effect, since it tapelist is an end-result file, not a "read-at-start" config file ... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
How to fix annoying break in tape sequence?
Hello, We have a four-week, five days per week cycle: dumpcycle 7 days runspercycle 5 tapecycle 20 tapes These twenty tapes are named OurName-A-Mon, OurName-A-Tue, ..., OurName-A-Fri, OurName-B-Mon, ..., OurName-D-Fri (in other words, the letters A, B, C, D refer to weeks in the four-week cycle): Week 1: A-Mon on Monday, A-Tue on Tuesday, A-Wed on Wednesday etc. Week 2: B-Mon on Monday, B-Tue on Tuesday etc. Week 3: C-Mon ... C-Fri Week 4: D-Mon ... D-Fri Last Friday, we were due to use OurName-B-Fri, but because of a disk space problem in /var/log, the job failed. AMANDA is still expecting to use OurName-B-Fri, rather than OurName-C-Mon which would be part of the usual schedule. After putting OurName-C-Mon in the drive, amcheck produces this: ERROR: cannot overwrite active tape OurName-C-Mon (expecting tape OurName-B-Fri or a new tape) Tried a suggestion I found in the AMANDA FAQ, which was to set OurName-B-Fri as "no-reuse" so that it wouldn't ask for it, but this still wouldn't make it want to use OurName-C-Mon: ERROR: cannot overwrite active tape CRUK-Weekly-C-Mon (expecting a new tape) What can I try here? Basically, the contents of both OurName-B-Fri and OurName-C-Mon are 'disposable', since they are both due to be overwritten in any case. Comments suggesting that "using the day-of-the-week in the label is a bad idea" won't be considered helpful, although I have a feeling that may be something I'll hear ... :-) Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Closed list
On Monday, 17.11.2003 at 07:30 -0500, Todd Kover wrote: > Until I can get a better solution in place for filtering out > irrelevent mail, both amanda-users and amanda-hackers are now closed > for posting to non-subscribers. At some point, this will change, but > it will coincide with some better filtering software. What are the reasons for not *keeping* them as closed lists? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Rename tape labels?
On Friday, 31.10.2003 at 17:07 -0500, Eric Siegerman wrote: > > Is there anyway I can change tape label names after I'm well into > > amanda dumpcycle? I currently have TLS-Set-1-01.. Set-1-02.. > > Set-2-01 and so on. I want to get rid of this set concept from the > > label. > > This is untested; treat it with caution... > > 1. To begin the process, change the "labelstr" regexp in > amanda.conf so that both the old and new label styles are > recognized. > > 2. For the next tapecycle's worth of dumps, you'll have a mix of > old- and new-style labels. Each day that a tape with an > old-style label comes up to be reused: > a. Do "amrmtape " > > b. Relabel the tape with a new-style label. Amanda will > consider it to be a "new tape", but that's ok. > > 3. After all of the old-style tapes have been relabelled, change > "labelstr" again, to only accept the new style of labels > > > WARNINGS: > - DO NOT do (2) all at once for all of the tapes; you'll > clobber your backups. Make sure you do those steps, for each > tape, just before Amanda would have overwritten that tape > anyway. > > - If you're still on your first tapecycle, i.e. you're still > adding new tapes one at a time, you'll have to finish adding > in your new tapes before you can even begin step (2). > > - During this process, you're circumventing all (or most) of > Amanda's protections against clobbering the wrong tape. So > be careful! I'm interested in doing this too, for various reasons. Anyone actually tried something like this? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: slow amanda performance on ONE system.
On Tuesday, 04.11.2003 at 10:05 -0500, Gene Heskett wrote: > On Tuesday 04 November 2003 09:57, Toomas Aas wrote: > >> You have over 5 gigabytes of mail? I find that hard to believe, > >> not even a major spammer would have that much. > > > >Alas. These days, when just about everybody sends mail in HTML > > format, it is customary to send HUGE .doc files back and forth and > > nobody ever deletes any old mail, it is not that uncommon. > > > >Just an example from our mail server (ca 300 users): > > > >[EMAIL PROTECTED]:/data# du -h --max-depth=1 | grep MAIL > >21G ./MAIL > > Good grief Toomas! Can you not institute a mail box size limit, about > 10 megs maybe? Depends on the context, of course. An IMAP server where all mail is stored on the server (including sub-folders, possibly going back many years etc.) you could justifiably need a few hundred megs for each user, perhaps more. Toomas's 21GB for 300 users equates to about 70MB per user, which doesn't sound too silly. If this is just the mail *spool*, however (it's not totally clear from the example), I would have thought that it would affect performance (especially to remote users accessing their spools) to have spool files of that size. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
On Friday, 13.06.2003 at 12:49 +0200, Paul Bijnens wrote: > >A stat of one of the files on the ncp filesystem looks like this: > > > > File: "pm-net2.ini" > > Size: 14025 Blocks: 28 IO Block: -4611692065741340160 > > Regular File > >Device: 15h/21d Inode: 1517Links: 1 > >Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) > >Access: Wed Jun 11 00:00:00 2003 > >Modify: Wed Jun 4 12:08:00 2003 > >Change: Tue Jun 3 11:07:06 2003 > > > >This file, according to its timestamp was changed at 12:08 on June 4th. > > The mtime + the inode number are compared by gnutar. > Maybe linux fakes inodes for ncpmounts and maybe they don't stay > constant between mounts. > Have a look at the files in gnutar-lists. They look like: > > 35651587 423837 ./lant/lib > 35651587 891648 ./lant24/var/spool/data/in > 35651587 341248 ./lant24/Nl-Fr > 35651587 522880 ./lant24/En-SN/lib > 35651587 181633 ./lant/En-Es > > The first number is the mtime (in seconds since epoch), the second > number is the inode number, followed by the filename. > You find files named: (in perl notation:) > $host . "_" . ($dir =~ s!/!_!g) . $level > A e.g. host__0 for the level 0 backup of the root filesystem. > A level 1 backup is compared to the status of the last level 0 backup. Hmmm - the 'seconds since epoch' is clearly wrong for all the Netware gnutar lists (it is showing 0, rather than something corresponding approximately to 'this year'). Seems like the Netware mount is getting a rogue timestamp which is making AMANDA think everything is new. Your help has been useful - you may have directed me towards the real problem. Now all I need to do is figure out the right way to mount the Netware filesystems ... Thanks Paul, Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
On Friday, 13.06.2003 at 09:39 +0200, Paul Bijnens wrote: > >If I am not wrong, amanda needs to update some information on the > >files it had backed-up, in order to keep track of what file are > >changing or not since last back-up. > > Yes, but not in the files or inodes itself. > That tracking info managed by amanda and is stored in the directory > you specified when compiling amanda (--with-gnutar-listdir=...), > probably ~/amanda/gnutar-lists. A stat of one of the files on the ncp filesystem looks like this: File: "pm-net2.ini" Size: 14025 Blocks: 28 IO Block: -4611692065741340160 Regular File Device: 15h/21d Inode: 1517Links: 1 Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) Access: Wed Jun 11 00:00:00 2003 Modify: Wed Jun 4 12:08:00 2003 Change: Tue Jun 3 11:07:06 2003 This file, according to its timestamp was changed at 12:08 on June 4th. Does anything look odd, apart from that? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
On Thursday, 12.06.2003 at 12:12 -0400, Jon LaBadie wrote: > Unix, in the inode allocated to each file, keeps three time stamps, > collectively known as "mac"time stamps as they are "data > Modification", "data Access", and "inode Change" times. > > Not all OS's keep these same 3 time stamps, yet to make nfs mounts > work (I presume ncpmount is really doing an underlying nfs mount or > something similar) the mactimes have to mimiced for use within a unix > system. > > I can see a maping of "ctime" for example just tracking "mtime", or > maybe registering the date and time of the ncpmount command or ??? > Anything that might throw tar off when it goes and looks "has any > change occured". > > Just a thought with no facts. OK, some stuff for me to check out - thanks Jon. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: Q: Backing up Netware3 via ncpfs?
On Thursday, 12.06.2003 at 11:59 +0100, Martin Hepworth wrote: > how are you backing up the mount point? gnutar I guess, in which case > are you using the latest version... Using tar, version 1.13.25 ... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Q: Backing up Netware3 via ncpfs?
Dear all, Recently added a couple of netware servers to our Amanda backup regime - I used ncpmount to give the servers mount points and added the mount points to the disklist. The files backed up successfully on their first night, as a 'level 0' full backup; however, I notice today that the next night's 'level 1' backup actually appears to have backed up all files again, despite the fact that very few files will have changed. The servers are Netware 3 servers, and have been mounted read-only using: ncpmount -S server -U username -f 444 -d 555 /mount/point/blah I can't find anything helpful in the archives about backing up Netware servers in this way. Anyone got any hints? Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: client was working, now suddenly is getting self check "host down?" errors
On Monday, 02.06.2003 at 10:43 +0100, Martin Hepworth wrote: > >>>Any ideas of why a client would work for a while then randomly not > >>>be able to do a selfchecK? The other amanda client is still working > >>>great... > >> > >>I have a random problem like this as well running RH Linux. The > >>client occasionally fails amcheck in the afternoon. (Backups run at > >>nite.) When I look at portland, the client, I find the selfcheck > >>task "stuck" and I am unable to kill it, even with kill -9. See if > >>you have the same problem. On the client, try > >> > >>ps -ef | grep amand > >> > >>or grep with whatever your amanda user account is. > >> > >>If you see selfcheck running, you'll be unable to get amcheck on the > >>server to finish until it's gone. Just something to check. > > > > > >Interesting to see this problem reported - I've had this happen > >sporadically too. The 'host down' error relates to the localhost and > >it leaves 'selfcheck' and 'amandad' running in the background. The > >server is RH Linux 7.3, running AMANDA 2.4.2p2. > > > >However, killing those processes does not make everything better. > >The problem seems unrelated to the AMANDA configuration. The last > >time it happened here, we were fortunate enough to have a > >'maintenance window' and rebooted the server and after that amcheck > >ran without complaint. However, given that this is a production > >server, rebooting is not a good solution. > > do you use 'localhost' or 'hostname' in the disk list. > > I perfer to use 'hostname' for the reason that if you move the amanda > server to 'someotherhostname' all the tapes etc still reflect the > correct hosts! We use 'localhost' ... :-) > what do the debug logs in /tmp/amanda say when this happens, also > anything else in /var/log/messages indication anything odd at this > time? Nothing obviously helpful - the only difference between a working and non-working copy of the selfcheck and amcheck debugs are the timestamps and process IDs. The amandad debugs show "amandad: dgram_recv: timeout after 10 seconds" a few times followed by a "amandad: waiting for ack: timeout, giving up!" message a little later. As I said this is a Problem That Goes Away By Itself. I was wondering if there was some sort of DNS thing going on, but I couldn't get anywhere with that ... Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Re: client was working, now suddenly is getting self check "host down?" errors
On Friday, 30.05.2003 at 15:04 -0400, Ron Bauman wrote: > > Any ideas of why a client would work for a while then randomly not > > be able to do a selfchecK? The other amanda client is still working > > great... > > I have a random problem like this as well running RH Linux. The > client occasionally fails amcheck in the afternoon. (Backups run at > nite.) When I look at portland, the client, I find the selfcheck task > "stuck" and I am unable to kill it, even with kill -9. See if you > have the same problem. On the client, try > > ps -ef | grep amand > > or grep with whatever your amanda user account is. > > If you see selfcheck running, you'll be unable to get amcheck on the > server to finish until it's gone. Just something to check. Interesting to see this problem reported - I've had this happen sporadically too. The 'host down' error relates to the localhost and it leaves 'selfcheck' and 'amandad' running in the background. The server is RH Linux 7.3, running AMANDA 2.4.2p2. However, killing those processes does not make everything better. The problem seems unrelated to the AMANDA configuration. The last time it happened here, we were fortunate enough to have a 'maintenance window' and rebooted the server and after that amcheck ran without complaint. However, given that this is a production server, rebooting is not a good solution. Dave. -- Dave Ewart [EMAIL PROTECTED] Computing Manager, Epidemiology Unit, Oxford Cancer Research UK PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
