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 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
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
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
Can anyone explain this log error message?
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.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
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: 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
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 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 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
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-
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: 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-
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: 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: 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: 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: [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: 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-
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: 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-
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
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: 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
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: 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: 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
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: 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: 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: 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 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 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
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: 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
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: 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: 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: 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 config old-label 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: 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
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 mactime 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 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 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
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 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
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
