Re: tapedef for Sony SDX-D500C streamer
On Thursday 29 July 2004 10:35, Rainer Hofmann wrote: >Hi, > >I'm looking for a tapedefinition for tape type "Sony SDX2-50C 230m > 64k". I couldn't find an entry at the "tapelist" at amanda.org. > >Has anyone got a definition or can point me where to find the >"amtapetype" tool? > >Thanks! > >Rainer Hofmann Its in the distribution, although if you have an old rpm, it may be called just tapetype. In that event, find a newer rpm, or preferably, build it from a tarball. Generally, we'ed rather not have to deal with rpms as the tarball is so easy to make and install. I use a script, executed as the user amanda to do all the configuration and making, then become root to do the make install. The whole thing is about 5-6 minutes on a 1400XP athlon machine. This script gets posted every so often, so its not more than 2-4 weeks back in the lists archives. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.24% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: `RESULTS MISSING' error
On Tue, 13 Jul 2004, Geert Uytterhoeven wrote:
> I'm trying to make Amanda backup my home network (several Linux machines) to
> disk. My first plan is to specify a non-existent tape drive (I don't have a
> tape drive anymore), and just copy the archives from the holding disk to a
> remote disk.
>
> However, I always (for both local and remote disks) get the following error
> (after the missing tape error, of course):
>
> anakin sda5 RESULTS MISSING
>
> I started from the amanda.conf I used to backup to DDS tape some years ago, so
> I'm quite sure it's not a problem with the config file. Basically I just added
> `reserve 20'. Am I missing something?
>
> If needed, I can tar-up /tmp/amanda/.
>
> Or should I use the `file' output driver? It seems to be less flexible to me.
So I tried the `file' output driver and `chg-disk', using 8 virtual tapes...
| tpchanger "chg-disk"
| changerfile "/etc/amanda/DailySet1/changer"
| tapedev "file:/scratch/amanda/DailySet1"
| tapetype HARD-DISK
| labelstr "DAILY[0-9][0-9]*$"# label constraint regex: all tapes must match
Labeling the tapes (8 tapes) worked fine.
Amcheck runs fine:
| # su - backup amcheck DailySet1
| Amanda Tape Server Host Check
| -
| amcheck-server: slot 8: date Xlabel DAILY08 (new tape)
| NOTE: skipping tape-writable test
| Tape DAILY08 label ok
| NOTE: info dir /var/lib/amanda/DailySet1/curinfo: does not exist
| NOTE: it will be created on the next run
| NOTE: index dir /var/lib/amanda/DailySet1/index/anakin: does not exist
| Server check took 0.217 seconds
|
| Amanda Backup Client Hosts Check
|
| Client check: 1 host checked in 0.178 seconds, 0 problems found
|
| (brought to you by Amanda 2.4.4p2)
| #
But amdump itself still fails:
| *** THE DUMPS DID NOT FINISH PROPERLY!
|
| The next tape Amanda expects to use is: a new tape.
| The next new tape already labelled is: DAILY01.
|
| FAILURE AND STRANGE DUMP SUMMARY:
| driver: FATAL reading result from taper: Connection reset by peer
| anakin sda5 RESULTS MISSING
|
|
| STATISTICS:
| Total Full Daily
|
| Estimate Time (hrs:min)0:00
| Run Time (hrs:min) 0:00
| Dump Time (hrs:min)0:00 0:00 0:00
| Output Size (meg) 0.00.00.0
| Original Size (meg) 0.00.00.0
| Avg Compressed Size (%) -- -- --
| Filesystems Dumped0 0 0
| Avg Dump Rate (k/s) -- -- --
|
| Tape Time (hrs:min)0:00 0:00 0:00
| Tape Size (meg) 0.00.00.0
| Tape Used (%) 0.00.00.0
| Filesystems Taped 0 0 0
| Avg Tp Write Rate (k/s) -- -- --
|
| ?
| NOTES:
| planner: Adding new disk anakin:sda5.
|
| ?
| DUMP SUMMARY:
| DUMPER STATSTAPER STATS
| HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
| -- -
| anakin sda5 MISSING --
|
| (brought to you by Amanda version 2.4.4p2)
I can send the contents of /tmp/amanda/* if you need them, but I didn't see
anything fishy there.
Anyone with a clue? Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: HUGE estimation time
On Thu, 29 Jul 2004 at 11:10am, Narada Hess wrote > I was having estimation timeout failures, so based on advice from this > group (thanks), I increased the etimout value in amanda.conf from 600 to > 6000. Yay, now my backups work! But I am frankly astonished at the fact > that estimation took almost twice as long as the actual dump. Is this > normal, or is there some way to speed this up? That depends. The estimate phase with tar (which from below is what I assume you're using) does tar cf /dev/null (among some other flags). So it just stats the files, it doesn't actually read them off the disk. This is generally *very* fast. But if you have a case pathological to your filesystem (e.g. *lots* of very small files), it can be slowed down immensely. If you look in the sendsize*debug file, you can figure out exactly how long each estimate is taking, and then examine that FS. > Another concern is that the k/s rate is so slow. We are backing to an > LTO-L1 drive which in normal use seems to run at about twice the > reported speed. Does Amanda have a lot of overhead that is slowing > things down? I guess I should do a straight gnu-tar dump and compare the > transfer rates. > Avg Dump Rate (k/s) 9949.6 9949.6-- > > Avg Tp Write Rate (k/s) 9948.6 9948.6-- Your dump and tape write speeds are the same, so you're not using a holding disk. Holding disks can definitely speed things up. Is the amanda server also the client? If not, then what you're seeing is simply network speed. If so, then, yes, do some benchmarking and make sure your disks can keep up with the tape drive. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
HUGE estimation time
Title: Message Hi folks, I was having estimation timeout failures, so based on advice from this group (thanks), I increased the etimout value in amanda.conf from 600 to 6000. Yay, now my backups work! But I am frankly astonished at the fact that estimation took almost twice as long as the actual dump. Is this normal, or is there some way to speed this up? Another concern is that the k/s rate is so slow. We are backing to an LTO-L1 drive which in normal use seems to run at about twice the reported speed. Does Amanda have a lot of overhead that is slowing things down? I guess I should do a straight gnu-tar dump and compare the transfer rates. We are dumping from a Linux RH 8 system. Amanda report details follow. Thanks for any light you can shed on this. STATISTICS: Total Full Daily Estimate Time (hrs:min) 6:07Run Time (hrs:min) 9:40Dump Time (hrs:min) 3:33 3:33 0:00Output Size (meg) 124185.9 124185.9 0.0Original Size (meg) 124185.9 124185.9 0.0Avg Compressed Size (%) -- -- --Filesystems Dumped 4 4 0Avg Dump Rate (k/s) 9949.6 9949.6 -- Tape Time (hrs:min) 3:33 3:33 0:00Tape Size (meg) 124185.9 124185.9 0.0Tape Used (%) 60.6 60.6 0.0Filesystems Taped 4 4 0Avg Tp Write Rate (k/s) 9948.6 9948.6 -- USAGE BY TAPE: Label Time Size % Nb DailySet1-007 3:33 124185.9 60.6 4 . . . Narada HessAdvanced Digital Information Corporation3170 Coronado Drive, Santa Clara, CA 95054408 350-1409
Re: Encrypted backups
> You don't have to put gzip in the pipeline. Gpg compresses data by default > (zlib level 6, according to gpg(1)), before doing encryption. Excellent. Is there an official way of encrypting amanda, or just doing it this way? Note that there is also support for using krb4 to encrypt the stream over the network, but this results in cleartext backups on the holding disk and on tape. It's also hard to set up if you don't already grok kerberos. -- Greg Troxel <[EMAIL PROTECTED]>
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 29 Jul 2004 15:27, you wrote:
> On Thu, 29 Jul 2004, Jon LaBadie wrote:
> > - the position of gzip in the pipeline was wrong in my view.
> > it came after encryption meaning it was working on somewhat
> > randomized data. Thus the compression would likely be small.
>
> You don't have to put gzip in the pipeline. Gpg compresses data by default
> (zlib level 6, according to gpg(1)), before doing encryption.
Excellent. Is there an official way of encrypting amanda, or just doing it
this way?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> [EMAIL PROTECTED]
>
> In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that. -- Linus Torvalds
- --
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 587369
M +44 (0) 7930 323266
F +44 (0) 1224 742001
E [EMAIL PROTECTED]
Open Source. Open Solutions.
http://www.suretecsystems.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBCQ9QeWseh9tzvqgRAveyAJ0QOgmbteprPFoCSZV2/hca2zm3qQCfefi2
b25SjgmJgOmbsTilzNw3ddI=
=jOaX
-END PGP SIGNATURE-
tapedef for Sony SDX-D500C streamer
Hi, I'm looking for a tapedefinition for tape type "Sony SDX2-50C 230m 64k". I couldn't find an entry at the "tapelist" at amanda.org. Has anyone got a definition or can point me where to find the "amtapetype" tool? Thanks! Rainer Hofmann
Re: Encrypted backups
On Thu, 29 Jul 2004, Jon LaBadie wrote:
> - the position of gzip in the pipeline was wrong in my view.
> it came after encryption meaning it was working on somewhat
> randomized data. Thus the compression would likely be small.
You don't have to put gzip in the pipeline. Gpg compresses data by default
(zlib level 6, according to gpg(1)), before doing encryption.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE:Re: partition failing to backup
-> increase dtimeout
Re: Encrypted backups
On Thu, Jul 29, 2004 at 10:03:22AM +0100, Gavin Henry wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wednesday 28 Jul 2004 18:34, you wrote: > > Gavin, > > > > I set this up a few years back and it rocked! > > > > http://security.uchicago.edu/tools/gpg-amanda/ > > Thanks, I've had a read. How much does this slow down the backup? I take it > clients need to do client side compression in order for nothing to be sent > clear text across the wire? > > > > > On Wed, 2004-07-28 at 13:18, Gavin Henry wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Hi all, > > > > > > Has this been discussed before? > > > > > > I was thinking of using a encrypted filesystems for the tmp storage, then > > > dumping that to tape? > > > It has been a while since I read that document so my memory may be imperfect. Two things I seem to recall: - compression is optional, just like in amanda in general - the position of gzip in the pipeline was wrong in my view. it came after encryption meaning it was working on somewhat randomized data. Thus the compression would likely be small. But recall, I've never used the system, just impressions from reading. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: partition failing to backup
In a message dated: Thu, 29 Jul 2004 10:55:03 BST "Ranveer Attalia" said: >FAILURE AND STRANGE DUMP SUMMARY: >telsupp2 /opt lev 0 FAILED [data timeout] > >/-- telsupp2 /opt lev 0 FAILED [data timeout] >sendbackup: start [telsupp2:/opt level 0] >sendbackup: info BACKUP=/sbin/vxdump >sendbackup: info RECOVER_CMD=/sbin/vxrestore -f... - >sendbackup: info end >| vxdump: Date of this level 0 dump: Thu Jul 29 01:50:45 2004 >| vxdump: Date of last level 0 dump: the epoch >| vxdump: Dumping /dev/vg01/rlvol2 to standard output >| vxdump: mapping (Pass I) [regular files] >| vxdump: mapping (Pass II) [directories] >| vxdump: estimated 14433064 blocks (7047.39MB) on -0.01 tape(s). >| vxdump: dumping (Pass III) [directories] >\ > >telsupp2 /opt 0 FAILED --- > > >This is the contacts of the Daily configuration script: disklist >telsupp2 / always-full >telsupp2 /usr always-full >telsupp2 /var always-full >telsupp2 /stand always-full >telsupp2 /opt always-full >telsupp2 /home always-full >telsupp2 /databases always-full > >I am not sure what is happening here, I have checked out the >amandad.debug file but it doesn't give me any kind of indication. > >Has anyone got any ideas? Did you check the permissions on that partition? Does the amanda user have rw privs on it? Without seeing more of the debug files, it's tough to say. -- Seeya, Paul GPG Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE If you're not having fun, you're not doing it right!
partition failing to backup
This is the dialy email I receive from amanda: FAILURE AND STRANGE DUMP SUMMARY: telsupp2 /opt lev 0 FAILED [data timeout] /-- telsupp2 /opt lev 0 FAILED [data timeout] sendbackup: start [telsupp2:/opt level 0] sendbackup: info BACKUP=/sbin/vxdump sendbackup: info RECOVER_CMD=/sbin/vxrestore -f... - sendbackup: info end | vxdump: Date of this level 0 dump: Thu Jul 29 01:50:45 2004 | vxdump: Date of last level 0 dump: the epoch | vxdump: Dumping /dev/vg01/rlvol2 to standard output | vxdump: mapping (Pass I) [regular files] | vxdump: mapping (Pass II) [directories] | vxdump: estimated 14433064 blocks (7047.39MB) on -0.01 tape(s). | vxdump: dumping (Pass III) [directories] \ telsupp2 /opt 0 FAILED --- This is the contacts of the Daily configuration script: disklist telsupp2 / always-full telsupp2 /usr always-full telsupp2 /var always-full telsupp2 /stand always-full telsupp2 /opt always-full telsupp2 /home always-full telsupp2 /databases always-full I am not sure what is happening here, I have checked out the amandad.debug file but it doesn't give me any kind of indication. Has anyone got any ideas? Thanks v.much - Ranveer Tertio Telecoms (www.telco-tertio.com) Head Office: One Angel Square Torrens Street London EC1V 1PL Tel: +44 (0)20 7843 4000 - Fax: +44 (0)20 7843 4001 Bath Office: Riverside Buildings 108 Walcot Street Bath BA1 5BG Tel: +44 (0)1225 478000 - Fax: +44 (0)1225 478001 Munich Office: Freisinger Strasse 10, 85737 Ismaning/Munich, Germany, Tel: +49 (0)89 665506 41 - Fax: +49 (0)89 665506 99 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Tertio Ltd. This email has been scanned by the MessageLabs Email Security System.
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 29 Jul 2004 09:20, you wrote: > 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. - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E [EMAIL PROTECTED] Open Source. Open Solutions. http://www.suretecsystems.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCL1qeWseh9tzvqgRApojAJ9oM67P/hxYKORGhpeo9ZQ48j5HPACfW/Wb /FAliNRv4ksPo+UEronupqQ= =n97C -END PGP SIGNATURE-
Re: Encrypted backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 28 Jul 2004 18:34, you wrote: > Gavin, > > I set this up a few years back and it rocked! > > http://security.uchicago.edu/tools/gpg-amanda/ Thanks, I've had a read. How much does this slow down the backup? I take it clients need to do client side compression in order for nothing to be sent clear text across the wire? > > Drew > > On Wed, 2004-07-28 at 13:18, Gavin Henry wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi all, > > > > Has this been discussed before? > > > > I was thinking of using a encrypted filesystems for the tmp storage, then > > dumping that to tape? > > > > Gavin. > > > > - -- > > Kind Regards, > > > > Gavin Henry. > > Managing Director. > > > > T +44 (0) 1224 587369 > > M +44 (0) 7930 323266 > > F +44 (0) 1224 742001 > > E [EMAIL PROTECTED] > > > > Open Source. Open Solutions. > > > > http://www.suretecsystems.com/ > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.2.4 (GNU/Linux) > > > > iD8DBQFBB9/6eWseh9tzvqgRArMCAKCU1CGYGVGxvzwuTWbJBRsUR46A6QCeJItu > > hXZvPIfcLzGmpEDGCh7Ihnw= > > =nW8r > > -END PGP SIGNATURE- - -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E [EMAIL PROTECTED] Open Source. Open Solutions. http://www.suretecsystems.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBCL1aeWseh9tzvqgRAjo0AJ0V5yywWZ3NDMdZbQQIRj8IeXpkeQCgnWyt SDpDaQ7BQmLpU8eZ2OO107o= =3Eri -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: Cataloging tapes from a previouse system
Chris Lee wrote: I have a set of tapes from a previous server, it is thought that there may be some files on these tapes that are important. I have created a similar config file to the one that existed on the old server and am now wanting to update that config with the appropriate database information. What do I run to get the databases built from these tapes? You want a Table of Contents of each tape (host, disk, level), and you want an index if possible. Is that correct? The amanda tapes are selfdescribing. They contain enough information to be able to restore. But there needs to be a human that interprets the info and then acts more or less intelligent. Currently there is no easy way to build an amanda-usable TOC or index from tapes alone. The best thing is try to restore the amanda home directory that did contain all these things before. It is explained in docs/RESTORE too, under the section "5) Server machine fails, non-system critical, amanda disk, with db." But I guess you don't have the "amadmin export" that they talk about. Moreover, that "curinfo" database contains only the info of the last dumpcycle. If your tapes cover more dumpcycles, then you'll need the logfiles too. For a table of contents (hosts, disk, level, date), use a shellscript like this: #!/bin/sh TAPEDEV= while mt -f $TAPEDEV fsf 1 ; do dd if=$TAPEDEV bs=32k count=1 | head -1 sleep 1 done Or change the "head -1" to "tr -d '\0'" for even more information. Once you find the previous amanda directory, restore that, and you'll be ready to use the more userfriendly amrecover. Thanks Chris Lee -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
