Re: amtape DailySet1 show --- asks for slot 2 ??
On Thu, Jul 13, 2006 at 08:19:12PM -0700, Brian Neu wrote: > I'm confused. > > Why does this command eject the tape and then ask for me to insert a tape > into slot 2? > > > -sh-3.1$ amtape DailySet1 show > changer: got exit: 0 str: 1 99 1 > changer_query: changer return was 99 1 > changer_query: searchable = 0 > amtape: scanning all 99 slots in tape-changer rack: > changer_find: looking for NULL changer is searchable = 0 > changer: got exit: 0 str: 1 /dev/nst0 > slot 1: date Xlabel DailySet1-04 > insert tape into slot 2 and press return It appears you are using the chg-manual tape changer script. I'm guessing it is configured for "99 slots". With the "show" command of amtape you have asked it to tell you which tape is in each of the 99 slots. As the changer is "manual" who, except you, is supposed to change the tapes? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
amtape DailySet1 show --- asks for slot 2 ??
I'm confused.Why does this command eject the tape and then ask for me to insert a tape into slot 2?-sh-3.1$ amtape DailySet1 show changer: got exit: 0 str: 1 99 1 changer_query: changer return was 99 1 changer_query: searchable = 0 amtape: scanning all 99 slots in tape-changer rack: changer_find: looking for NULL changer is searchable = 0 changer: got exit: 0 str: 1 /dev/nst0 slot 1: date Xlabel DailySet1-04 insert tape into slot 2 and press return
Re: Exclude list entries
> No there really is a difference between excluding /foo, ./foo, and foo. > As you are backing up ".", /foo will not match anything. Of course > ./foo will match any foo in the top level directory "." > foo will match any foo in any directory under . Not so sure: banyan: /usr/local/bin/tar --version tar (GNU tar) 1.13.25 Copyright (C) 2001 Free Software Foundation, Inc. This program comes with NO WARRANTY, to the extent permitted by law. You may redistribute it under the terms of the GNU General Public License; see the file named COPYING for details. Written by John Gilmore and Jay Fenlason. banyan: /usr/local/bin/tar cfv /dev/null . | grep jpg ./Images/Picture-2 003.jpg ./Images/Picture-2 005.jpg ./maman.jpg banyan: cat ../excl ./*.jpg banyan: /usr/local/bin/tar cfv /dev/null --exclude-from=../excl . | grep jpg banyan: cat ../excl2 *.jpg banyan: /usr/local/bin/tar cfv /dev/null --exclude-from=../excl2 . | grep jpg Excl contains ./*.jpg and excl2 contains *.jpg but they both exclude any .jpg file in any level of the hierarchy. OK, funny enough, tar 1.13.19 on another machine gives different results, but still, tar 1.13.25 is recommeneded version isn't it? Olivier
Re: Exclude list entries
On Fri, Jul 14, 2006 at 09:47:22AM +0700, Olivier Nicole wrote: > > "When AMANDA attempts to exclude a file or directory it does so relative to > > the area being archived. For example if /var is in your disklist and you > > want to exclude /var/log/somefile, then your exclude file would contain > > ./log/somefile" > > I understand that rather as a warning not to use /var in the path > > > I really just want to confirm whether or not I could have used the entries > > without ./ and what the difference between the different sets of entries > > would be. > > I think it does not make any difference (except maybe for path > globing?), it will exclude any file ending with the suffix .ora, in > any subdirectory that you are backuping. No there really is a difference between excluding /foo, ./foo, and foo. As you are backing up ".", /foo will not match anything. ./foo will match any foo in the top level directory "." foo will match any foo in any directory under . > > The exclude list is handed as-is to gnu-tar, so one way to make sure > it does what you want is to try it with gnu-tar manually. and it is fast if you do it to /dev/null, as in gtar cvf /dev/null -exclude 'whatever' . -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Amanda cygwin client behind a firewall
> Is anyone else backuping up an amanda cygwin client, where the cygwin > client sits behind a firewall and the server sits on the outside of the > firewall? It does not make any difference if your client is cygwin or any other flavor of Unix. You would have to adapt what you call inside and outside, but here what I have open on my firewall: UDP from server to client port=10080 UDP from client port=10080 to server (because there may be a VERY long time between the server request and the client response, and the firewall table would expire before the response is sent; this rule is the oposite of the previous one). TCP from server to client (on any port, because the client will inform the server of the specific ports it wants to use at each run. There is a module in iptable/ipchain to manage that, there is a way to restric the list of ports being used and then the list of ports to keep open. In my case the firewall is protecting the server, so opening outgoing ports is not so much an issue.) TCP from client to server port=10082 TCP from client to server port=10083 (for indexing purpose? or for amrestore to access the index server?) Bests, Olivier
Re: Exclude list entries
> "When AMANDA attempts to exclude a file or directory it does so relative to > the area being archived. For example if /var is in your disklist and you > want to exclude /var/log/somefile, then your exclude file would contain > ./log/somefile" I understand that rather as a warning not to use /var in the path > I really just want to confirm whether or not I could have used the entries > without ./ and what the difference between the different sets of entries > would be. I think it does not make any difference (except maybe for path globing?), it will exclude any file ending with the suffix .ora, in any subdirectory that you are backuping. The exclude list is handed as-is to gnu-tar, so one way to make sure it does what you want is to try it with gnu-tar manually. Best regards, Olivier
Re: Backup for specific files
> Please provide the details is there any restrictions > to provide to take the backup for the file type? Amanda is design to backup directories and file systems, not just individual files. Beside, it is a way better idea to backup any file in a directory except a few one we are sure that we don't want, rather than to have to explicetly define a list of the files we want. If new file types are added, in the first approache we may end up backuping it even if we don't want them, in the second approach we would not backup them while we do need a backup. Exclude list is the safe awy of doing it. Olivier
Re: Problems using amanda to backup SMB shares
> My point is that I do NOT have any /etc/amandates on server, NOR > clients. Although, Olivier Nicole states that I can simply create my > own, and amanda will use it; I remain unclear about this file, because I > do NOT find it documented anywhere ?!?! As far as I remember, I do create it by hand each time. But my way of installing things is usually quite old fashioned :) Olivier
Re: Port NNNN not secure (revisited)
Mike Allen wrote: After some helpful email from Frank Smith off-list I have decided to try a different approach to slve my problem: Here is an excerpt from my tape-server /etc/services file. amanda 20080/udp #Dump server control amandaidx 20082/tcp #Amanda indexing amidxtape 20083/tcp #Amanda tape indexing Note that I am not using the standard ports for amanda et al. A tcpdump from the client end of the communication between host 'familyserv' and host 'famrad' went as follows: 14:57:55.661773 IP familyserv.familyradio.org.ssh > famrad.familyradio.org.44233: P 1048606257:1048606385(128) ack 4160186819 win 33304 14:57:55.665181 IP famrad.familyradio.org.44233 > familyserv.familyradio.org.ssh: . ack 128 win 33240 123825301 449488402> 14:58:06.382636 IP famrad.familyradio.org.34932 > familyserv.familyradio.org.amanda: UDP, length: 119 14:58:06.423680 IP familyserv.familyradio.org.amanda > famrad.familyradio.org.34932: UDP, length: 50 14:58:06.424676 IP familyserv.familyradio.org.amanda > famrad.familyradio.org.34932: UDP, length: 109 14:58:06.428009 IP famrad.familyradio.org.34932 > familyserv.familyradio.org.amanda: UDP, length: 50 Since both ends are supposedy configured for tcpportrange=512.1023 and udpportrange=5,50100 try configure with "--with-tcpportrange=5,50100 --with-udpportrange=512,1023 ..." and recompile. Open the corresponding ports in the firewall setup. The reason udp port 34932 was tried because Amanda cannot find a reserved udp port that it can use. -- Thank you! Kevin Till Amanda documentation: http://wiki.zmanda.com Amanda forums:http://forums.zmanda.com
Re: Partial backup
On Thu, Jul 13, 2006 at 05:34:50PM -0500, James Wilson wrote: > Here is an amstatus before and after the backup. Before it estimated > 1231m but after it only backed up 171m. Howcome amanda isn't backing up > everything? amstatus is not the tool to use. After a dump you should receive a report via email. If you don't are not getting them, they can be regenerated with amreport. It looks to me like these are status reports from two different runs of amdump. Note, if you run it without an amdump actively running, amstatus reports on the previous run. You say the first was "before" the backup. That would suggest it is the status of the previous backup. It does not report the status of the file system in preparation for a future run of amdump. > > amanda.transolutions.net://192.168.1.133/ifxsessions 0 1231m partial > estimate done > > SUMMARY part real estimated > size size > partition : 1 > estimated : 1 1231m > flush : 0 0m > failed : 00m ( 0.00%) > wait for dumping: 00m ( 0.00%) > dumping to tape : 00m ( 0.00%) > dumping : 0 0m 0m ( 0.00%) ( 0.00%) > dumped : 0 0m 0m ( 0.00%) ( 0.00%) Nothing was dumped on this run. > wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) > wait to flush : 0 0m 0m (100.00%) ( 0.00%) > writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) > failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) > taped : 0 0m 0m ( 0.00%) ( 0.00%) > 32 dumpers idle : not-idle > taper idle > network free kps: 1001400 > holding space : 1m (100.00%) > 0 dumpers busy : 0:00:00 ( 0.00%) > sh-3.1$ amstatus tape > Using /etc/amanda/tape/amdump.1 from Thu Jul 13 16:29:51 CDT 2006 > > amanda.transolutions.net://192.168.1.133/ifxsessions 05m > finished (17:08:58) > > SUMMARY part real estimated > size size > partition : 1 > estimated : 1 171m > flush : 0 0m > failed : 00m ( 0.00%) > wait for dumping: 00m ( 0.00%) > dumping to tape : 00m ( 0.00%) > dumping : 0 0m 0m ( 0.00%) ( 0.00%) > dumped : 1 5m 171m ( 3.40%) ( 3.40%) It was not 171 mb that was dumped, the estimate was 171. What was dumped was 5 mb. > wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) > wait to flush : 0 0m 0m (100.00%) ( 0.00%) > writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) > failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) > taped : 1 5m 171m ( 3.40%) ( 3.40%) > 32 dumpers idle : no-dumpers > taper idle > network free kps: 1001400 > holding space : 1m (100.00%) > chunker0 busy : 0:00:00 ( 0.00%) > dumper0 busy : 0:08:59 ( 23.00%) > taper busy : 0:00:06 ( 0.27%) > 0 dumpers busy : 0:35:36 ( 91.02%)not-idle: 0:35:30 ( > 99.70%) > no-dumpers: 0:00:06 ( > 0.30%) > 1 dumper busy : 0:00:00 ( 0.00%) > Much more detail would be available from amreport. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
To whom it may concern
My best greetings to all of you, the amanda-users and -hackers, I contact you today as I feel the need to do so for quite a while now. -- As some of you might have noticed, my activities related to the Amanda-project are nearly non-existant for quite a while now. This has various reasons, and I won't bother you with details. I just want to "officially announce" that I am going into PASSIVE MODE now. I considered quitting my Amanda-Core-Team-Membership for a while, but when I look at the current core-team-member-list, I don't see any need to quit. -- Doing and living OpenSource is quite a lesson sometimes, individuals invest time and effort "to bring it on", but the return sometimes isn't very satisfying for the very individual. I have to revisit my priorities, as one of the "friends" (I use "" here, as I am shy to use that term in that context, although for me they are true friends) I "won" by doing Amanda-related work, told me: "That does seem to be the nature of life. Revisiting priorities on a frequent basis." And I do (thanks, X, you know ...) -- I am still believing in Amanda, as I use and promote it at various customers sites, but I am somehow tired of and frustrated by the way this project is developing over the last few years. I don't QUIT, as I still want to bring this piece of software forward, but things have changed in several ways and I have to accept the changes and adapt to the changes this project goes through. And I do. -- I am still open to any input/addition/correction/note related to the Amanda-docs, as I have put many many hours into the "renovation" of it. But I am also accepting the fact, that all this is not MINE and that I have to let it go as well. All the best to all of you, Stefan.
Port NNNN not secure (revisited)
After some helpful email from Frank Smith off-list I have decided to try a different approach to slve my problem: Here is an excerpt from my tape-server /etc/services file. amanda 20080/udp #Dump server control amandaidx 20082/tcp #Amanda indexing amidxtape 20083/tcp #Amanda tape indexing Note that I am not using the standard ports for amanda et al. A tcpdump from the client end of the communication between host 'familyserv' and host 'famrad' went as follows: 14:57:55.661773 IP familyserv.familyradio.org.ssh > famrad.familyradio.org.44233: P 1048606257:1048606385(128) ack 4160186819 win 33304 14:57:55.665181 IP famrad.familyradio.org.44233 > familyserv.familyradio.org.ssh: . ack 128 win 33240 123825301 449488402> 14:58:06.382636 IP famrad.familyradio.org.34932 > familyserv.familyradio.org.amanda: UDP, length: 119 14:58:06.423680 IP familyserv.familyradio.org.amanda > famrad.familyradio.org.34932: UDP, length: 50 14:58:06.424676 IP familyserv.familyradio.org.amanda > famrad.familyradio.org.34932: UDP, length: 109 14:58:06.428009 IP famrad.familyradio.org.34932 > familyserv.familyradio.org.amanda: UDP, length: 50 Since both ends are supposedy configured for tcpportrange=512.1023 and udpportrange=5,50100 why do I have ports like 34932 tring to be used in the master-slave commuinications? That port is not open on my firewall. I will appreciate any clues you may give me on this problem. (I don't have any.) Mike Allen
Partial backup
Here is an amstatus before and after the backup. Before it estimated 1231m but after it only backed up 171m. Howcome amanda isn't backing up everything? amanda.transolutions.net://192.168.1.133/ifxsessions 0 1231m partial estimate done SUMMARY part real estimated size size partition : 1 estimated : 1 1231m flush : 0 0m failed : 00m ( 0.00%) wait for dumping: 00m ( 0.00%) dumping to tape : 00m ( 0.00%) dumping : 0 0m 0m ( 0.00%) ( 0.00%) dumped : 0 0m 0m ( 0.00%) ( 0.00%) wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) wait to flush : 0 0m 0m (100.00%) ( 0.00%) writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) taped : 0 0m 0m ( 0.00%) ( 0.00%) 32 dumpers idle : not-idle taper idle network free kps: 1001400 holding space : 1m (100.00%) 0 dumpers busy : 0:00:00 ( 0.00%) sh-3.1$ amstatus tape Using /etc/amanda/tape/amdump.1 from Thu Jul 13 16:29:51 CDT 2006 amanda.transolutions.net://192.168.1.133/ifxsessions 05m finished (17:08:58) SUMMARY part real estimated size size partition : 1 estimated : 1 171m flush : 0 0m failed : 00m ( 0.00%) wait for dumping: 00m ( 0.00%) dumping to tape : 00m ( 0.00%) dumping : 0 0m 0m ( 0.00%) ( 0.00%) dumped : 1 5m 171m ( 3.40%) ( 3.40%) wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) wait to flush : 0 0m 0m (100.00%) ( 0.00%) writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) taped : 1 5m 171m ( 3.40%) ( 3.40%) 32 dumpers idle : no-dumpers taper idle network free kps: 1001400 holding space : 1m (100.00%) chunker0 busy : 0:00:00 ( 0.00%) dumper0 busy : 0:08:59 ( 23.00%) taper busy : 0:00:06 ( 0.27%) 0 dumpers busy : 0:35:36 ( 91.02%)not-idle: 0:35:30 ( 99.70%) no-dumpers: 0:00:06 ( 0.30%) 1 dumper busy : 0:00:00 ( 0.00%)
Re: making xfs dump work
On Thu, Jul 13, 2006 at 04:30:01PM -0400, Julian C. Dunn enlightened us: > >On Thu, 13 Jul 2006 at 3:57pm, Julian C. Dunn wrote > >>I have /usr/sbin/xfsdump already but Amanda doesn't seem to know how to > >>call it, even though sendsize is aware that it's an XFS filesystem: > > > >Was xfsdump there when you *compiled* amanda? That's when the locations > >of such things get noted. > > Ah... I'm using the binary vendor RPM which I assume doesn't contain XFS > support. Time to go compile my own. > I'd start here: http://www.math.ohiou.edu/~hyclak/casit/amanda/ -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263
Re: making xfs dump work
On Thu, 13 Jul 2006, Joshua Baker-LePain wrote: On Thu, 13 Jul 2006 at 3:57pm, Julian C. Dunn wrote I have /usr/sbin/xfsdump already but Amanda doesn't seem to know how to call it, even though sendsize is aware that it's an XFS filesystem: Was xfsdump there when you *compiled* amanda? That's when the locations of such things get noted. Ah... I'm using the binary vendor RPM which I assume doesn't contain XFS support. Time to go compile my own. - Julian [ Julian C. Dunn <[EMAIL PROTECTED]> * "You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby" ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
Re: making xfs dump work
On Thu, 13 Jul 2006 at 3:57pm, Julian C. Dunn wrote I have /usr/sbin/xfsdump already but Amanda doesn't seem to know how to call it, even though sendsize is aware that it's an XFS filesystem: Was xfsdump there when you *compiled* amanda? That's when the locations of such things get noted. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: making xfs dump work
On Thu, 13 Jul 2006, Jean-Francois Malouin wrote: * Julian C. Dunn <[EMAIL PROTECTED]> [20060713 15:44]: I've got a Linux workstation which uses xfs as one of its volumes (/dev/md2), but which I can't back up using Amanda because Amanda appears to call /sbin/dump on it, which under Linux blows up (/sbin/dump is ext2/3 only). How do I make Amanda call the "right" dump program (xfsdump rather than /sbin/dump)? Install xfsprogs. (at least on Debian that where you'll find xfsdump/xfsrestore). I think you will have to recompile Amanda though but I might be mistaken. I have /usr/sbin/xfsdump already but Amanda doesn't seem to know how to call it, even though sendsize is aware that it's an XFS filesystem: sendsize[11720]: time 2.976: getting size via dump for md2 level 0 sendsize[11720]: time 2.977: calculating for device '/dev/md2' with 'xfs' sendsize[11720]: time 2.977: running "/sbin/dump 0Ssf 1048576 - /dev/md2" sendsize[11720]: time 2.979: running /usr/lib64/amanda/killpgrp sendsize[11713]: time 2.979: waiting for any estimate child: 1 running sendsize[11720]: time 3.010: /dev/md2: Bad magic number in super-block while opening filesystem sendsize[11720]: time 3.011: DUMP: The ENTIRE dump is aborted. sendsize[11720]: time 3.011: . - Julian [ Julian C. Dunn <[EMAIL PROTECTED]> * "You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby" ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
Re: making xfs dump work
Oups! Forget that! xfsdump is a package by itself on Debian. Mea Culpa jf * Jean-Francois Malouin <[EMAIL PROTECTED]> [20060713 15:49]: > * Julian C. Dunn <[EMAIL PROTECTED]> [20060713 15:44]: > > I've got a Linux workstation which uses xfs as one of its volumes > > (/dev/md2), but which I can't back up using Amanda because Amanda appears > > to call /sbin/dump on it, which under Linux blows up (/sbin/dump is ext2/3 > > only). > > > > How do I make Amanda call the "right" dump program (xfsdump rather than > > /sbin/dump)? > > Install xfsprogs. > (at least on Debian that where you'll find xfsdump/xfsrestore). > I think you will have to recompile Amanda though but I might be mistaken. > > HTH > jf > > > > > - Julian > > > > [ Julian C. Dunn <[EMAIL PROTECTED]> * "You can throw confetti, ] > > [ WWW: www.aquezada.com/staff/julian * but you're still going ] > > [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby" ] > > [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ] -- <° ><
Re: making xfs dump work
* Julian C. Dunn <[EMAIL PROTECTED]> [20060713 15:44]: > I've got a Linux workstation which uses xfs as one of its volumes > (/dev/md2), but which I can't back up using Amanda because Amanda appears > to call /sbin/dump on it, which under Linux blows up (/sbin/dump is ext2/3 > only). > > How do I make Amanda call the "right" dump program (xfsdump rather than > /sbin/dump)? Install xfsprogs. (at least on Debian that where you'll find xfsdump/xfsrestore). I think you will have to recompile Amanda though but I might be mistaken. HTH jf > > - Julian > > [ Julian C. Dunn <[EMAIL PROTECTED]> * "You can throw confetti, ] > [ WWW: www.aquezada.com/staff/julian * but you're still going ] > [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby" ] > [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
making xfs dump work
I've got a Linux workstation which uses xfs as one of its volumes (/dev/md2), but which I can't back up using Amanda because Amanda appears to call /sbin/dump on it, which under Linux blows up (/sbin/dump is ext2/3 only). How do I make Amanda call the "right" dump program (xfsdump rather than /sbin/dump)? - Julian [ Julian C. Dunn <[EMAIL PROTECTED]> * "You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby" ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
Re: One backup server for two subnets
Hello: Ok, got it. Dumb mistake... /etc/xinetd.d/amanda disable = yes to disable = no Thanks, / Ronald Vincent Vazquez Senior Unix Systems Administrator Senior Network Manager Christ Tabernacle Church Ministries http://www.ctcministries.org (301) 540-9394 Home (240) 401-9192 Cell For web hosting solutions, please visit: http://www.spherenix.com/ > Hello: > > Yes, the server is the "router" between the two subnets. > > How do I configure the /etc/xinetd.d/amanda "only_from" section? Here is > what I have (example...): > > only_from = 1.2.3.0 4.5.6.0 > > Should this allow access from both subnets? 1.2.3.0 works fine but not > 4.5.6.0. > > Thanks again, > > / > Ronald Vincent Vazquez > Senior Unix Systems Administrator > Senior Network Manager > Christ Tabernacle Church Ministries > http://www.ctcministries.org > (301) 540-9394 Home > (240) 401-9192 Cell > > For web hosting solutions, please visit: > http://www.spherenix.com/ > >> On Thu, 13 Jul 2006 at 3:06pm, Ronald Vincent Vazquez wrote >> >>> I have been searching the web for a while now and haven't been able to >>> find an answer. Is it possible to set one backup server to handle two >>> different subnets? The backup server is ready to go, two configured >>> NICs. >>> >>> Any guidance on this issue would be great. >> >> Sure. Is 1 NIC on each subnet? I *did* have an issue once backing up >> across subnets. Well, I didn't, but the router sure didn't like it >> much... >> >> -- >> Joshua Baker-LePain >> Department of Biomedical Engineering >> Duke University >> > >
Re: One backup server for two subnets
Hello: Yes, the server is the "router" between the two subnets. How do I configure the /etc/xinetd.d/amanda "only_from" section? Here is what I have (example...): only_from = 1.2.3.0 4.5.6.0 Should this allow access from both subnets? 1.2.3.0 works fine but not 4.5.6.0. Thanks again, / Ronald Vincent Vazquez Senior Unix Systems Administrator Senior Network Manager Christ Tabernacle Church Ministries http://www.ctcministries.org (301) 540-9394 Home (240) 401-9192 Cell For web hosting solutions, please visit: http://www.spherenix.com/ > On Thu, 13 Jul 2006 at 3:06pm, Ronald Vincent Vazquez wrote > >> I have been searching the web for a while now and haven't been able to >> find an answer. Is it possible to set one backup server to handle two >> different subnets? The backup server is ready to go, two configured >> NICs. >> >> Any guidance on this issue would be great. > > Sure. Is 1 NIC on each subnet? I *did* have an issue once backing up > across subnets. Well, I didn't, but the router sure didn't like it > much... > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University >
Re: One backup server for two subnets
On Thu, 13 Jul 2006 at 3:06pm, Ronald Vincent Vazquez wrote I have been searching the web for a while now and haven't been able to find an answer. Is it possible to set one backup server to handle two different subnets? The backup server is ready to go, two configured NICs. Any guidance on this issue would be great. Sure. Is 1 NIC on each subnet? I *did* have an issue once backing up across subnets. Well, I didn't, but the router sure didn't like it much... -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
One backup server for two subnets
Hello list: I have been searching the web for a while now and haven't been able to find an answer. Is it possible to set one backup server to handle two different subnets? The backup server is ready to go, two configured NICs. Any guidance on this issue would be great. Thanks in advance, / Ronald Vincent Vazquez Senior Unix Systems Administrator Senior Network Manager Christ Tabernacle Church Ministries http://www.ctcministries.org (301) 540-9394 Home (240) 401-9192 Cell For web hosting solutions, please visit: http://www.spherenix.com/
Reset By Peer
Has anyone gotten these errors before and if so do you know why it happens? write_data: write failure. Error = Connection reset by peer ? write_socket: Error writing 39 bytes to socket 11: ERRNO = Connection reset by peer ? Error writing 39 bytes to client. -1 (Connection reset by peer) sendbackup: size 111879101 sendbackup: end
Re: planner: disk xxx:/, estimate of level N failed
Hi, It's not a bug in tar, it's a bug in amanda. The new file format is not compatible whit the way we read it. I will send a patch soon. Jean-Louis Jean-Louis Martineau wrote: Hi, I tried tar-1.15.91 and I have the same problem. tar-1.15.91 is buggy, you should not use it.
Re: planner: disk xxx:/, estimate of level N failed
Hi,
I tried tar-1.15.91 and I have the same problem.
tar-1.15.91 is buggy, you should not use it.
Jean-Louis
Geert Uytterhoeven wrote:
On Thu, 13 Jul 2006, Jean-Louis Martineau wrote:
| sendsize[11906]: argument list: /bin/tar --create --file /dev/null
--directory /home/p72 --one-file-system --numeric-owner --listed-incremental
/var/lib/amanda/gnutar-lists/anakin_home_p72_orig_3.new --sparse
--ignore-failed-read --totals --exclude-from
/tmp/amanda/sendsize._home_p72_orig.20060713004504000.exclude --files-from
/tmp/amanda/sendsize._home_p72_orig.20060713004504000.include
| sendsize[11906]: time 1.574: /bin/tar: Unexpected field value in snapshot
file
| sendsize[11906]: time 1.574: /bin/tar: Error is not recoverable: exiting
now
| sendsize[11906]: time 1.575: .
| sendsize[11906]: estimate time for /home/p72/orig level 3: 0.005
| sendsize[11906]: no size line match in /bin/tar output for "/home/p72/orig
It looks like the /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_3.new file
is corrupted. This file is a copy of
/var/lib/amanda/gnutar-lists/anakin_home_p72_orig_2.
IC.
Do you have free space in /var/lib/amanda/gnutar-lists/ ?
Yes.
Maybe it's a bug in tar?
which tar version?
1.15.91-1 and 1.15.91-2.
So probably it's a bug in tar, as it was upgraded from 1.15.1dfsg-3 to
1.15.91-1 on 2006-07-06 (according to /var/log/dpkg.log).
So the backup run of 2006-07-07 created the first corrupt files, which were
noticed first during the next run on 2006-07-08.
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: amrecover "Tape is not a dump tape" but amrestore works?
On Thu, 13 Jul 2006, Martin Hepworth wrote: What filesystems have you got on babelfish. FreeBSD 5.0 and later will use UFS2 as the default filesystem type, before this it was plain old UFS. hance the dump/restore programs will different, which is prob why it's not working. A-ha, you are probably right... babelfish has UFS2. Perhaps it's time to upgrade aphrodite, since FreeBSD 4.x is now obsolete :-) thanks Julian [ Julian C. Dunn <[EMAIL PROTECTED]> * "You can throw confetti, ] [ WWW: www.aquezada.com/staff/julian * but you're still going ] [ PGP: 91B3 7A9D 683C 7C16 715F* through the motions, baby" ] [ 442C 6065 D533 FDC2 05B9*- Aimee Mann ]
Re: planner: disk xxx:/, estimate of level N failed
Le jeudi 13 juillet 2006 15:16, Jean-Louis Martineau a écrit : > Hi, Hi, I have the same problem since a few days (using Amanda snapshot 2.5.1b1-20060623 with tar 1.15.91 to backup a single PC under Debian/Sid) > > | sendsize[11906]: time 1.574: /bin/tar: Unexpected field value in > > | snapshot file sendsize[11906]: time 1.574: /bin/tar: Error is not > > | recoverable: exiting now sendsize[11906]: time 1.575: . > > | sendsize[11906]: estimate time for /home/p72/orig level 3: 0.005 > > | sendsize[11906]: no size line match in /bin/tar output for I get exactly the same message and it's the only strange thing I could find in the logs > It looks like the > /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_3.new file is > corrupted. I agree, but I don't know what this file should look like. I tried to delete all the tar lists and force a level 0 which didn't help (the level 0 is good but the level 1 estimate still fails) > Do you have free space in /var/lib/amanda/gnutar-lists/ ? yes > Maybe it's a bug in tar? Maybe ; the 1.15.91 version introduced a new snapshot format and some other incompatible changes : http://lists.gnu.org/archive/html/bug-tar/2006-06/msg1.html But on the other hand, I also tried to manually copy the snapshot file and create a tar archive with the command line taken from 'runtar' and this worked fine. So it could be something to update in the way Amanda communicates with tar. thanks for your help -- Cédric Lucantis
Re: planner: disk xxx:/, estimate of level N failed
On Thu, 13 Jul 2006, Jean-Louis Martineau wrote:
> > | sendsize[11906]: argument list: /bin/tar --create --file /dev/null
> > --directory /home/p72 --one-file-system --numeric-owner --listed-incremental
> > /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_3.new --sparse
> > --ignore-failed-read --totals --exclude-from
> > /tmp/amanda/sendsize._home_p72_orig.20060713004504000.exclude --files-from
> > /tmp/amanda/sendsize._home_p72_orig.20060713004504000.include
> > | sendsize[11906]: time 1.574: /bin/tar: Unexpected field value in snapshot
> > file
> > | sendsize[11906]: time 1.574: /bin/tar: Error is not recoverable: exiting
> > now
> > | sendsize[11906]: time 1.575: .
> > | sendsize[11906]: estimate time for /home/p72/orig level 3: 0.005
> > | sendsize[11906]: no size line match in /bin/tar output for "/home/p72/orig
>
> It looks like the /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_3.new file
> is corrupted. This file is a copy of
> /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_2.
IC.
> Do you have free space in /var/lib/amanda/gnutar-lists/ ?
Yes.
> Maybe it's a bug in tar?
> which tar version?
1.15.91-1 and 1.15.91-2.
So probably it's a bug in tar, as it was upgraded from 1.15.1dfsg-3 to
1.15.91-1 on 2006-07-06 (according to /var/log/dpkg.log).
So the backup run of 2006-07-07 created the first corrupt files, which were
noticed first during the next run on 2006-07-08.
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: Dealing more gracefully with tape overruns
On Wed, Jul 12, 2006 at 04:30:12PM +0200, Ronan KERYELL wrote: > We run AMANDA for many years with the same taper and the time comes with > more and more users until one tape per day is sometimes not enough. :-/ > > We don't have any changer and often one tape is enough. So I would like a > mode where AMANDA would decide it is not possible to have everything on > one tape *but* would not stop dumping and would go on on the holding > disk. Then the autoflush mode would flush everything the day after or a > manual flush could be done on a separate tape. > > The problem is that when AMANDA notices that there is not enough space on > tape, it stops with messages such as: > minou.info.enstb.org /var lev 0 FAILED > [dumps too big, 180301 KB, but no incremental estimate] > minou.info.enstb.org /home lev 0 FAILED > [dumps too big, 3309778 KB, but no incremental estimate] > pei.info.enstb.org /mnt/bonbonne/subversion_backups lev 0 FAILED > [dumps too big, 1414910 KB, but cannot incremental dump new disk] > minou.info.enstb.org /export/bouteille lev 2 FAILED > [dumps way too big, 4632849 KB, must skip incremental dumps] > > I'd like to have incremental and even level 0 dumps on the holding disk, > where I have a lot of space. > > I've played recently with > maxdumpsize -1# Maximum number of bytes the planner will > schedule > # for a run (default: runtapes * tape_length). > but it doesn't help since it says it can decide to dump more than a tape > but it fails later with the same messages than above. > > So, is there an obvious way to deal with the not-so-frequent overrun we > encounter? > > If not, what about adding a new strategy with a mode such as: > dump-on-holding-disk-if-degraded-mode yes > Should not be to difficult to implement. > > I will try also to play with the reserve keyword next night with, for > example, reserve 50 % for full backups. > > reserve number > Default: 100. The part of holding-disk space that > should be reserved for incremental backups if no tape > is available, expressed as a percentage of the > available holding-disk space (0-100). By default, when > there is no tape to write to, degraded mode > (incremental) backups will be performed to the holding > disk. If full backups should also be allowed in this > case, the amount of holding disk space reserved for > incrementals should be lowered. > > But if it works, why this static allocation between incremental and full > backups? > > Another approach: what about also a mode with runtapes > 1 without any > changer, assuming that the user will use amflush later? > Close but no applause :( To get amanda to properly plan a day's dumps it will have to know it has additional capacity, otherwise it will try to restrict the dumps to what will fit a single tape. Thus, you are correct that increasing runtapes is needed. However, with a runtape > 1 you need a changer. And there just happens to be a changer script for changer-less drives. It is called chg-manual. So read through that script and configure it as your "changer". I suspect you will be able to daily put in 1 new tape. Yesterday's holding disk leftovers will go onto the tape first. I'm not certain, but I think that tape will still be considered as part of yesterdays' dump and today's files may not go onto it. An alternative is to artificially claim a larger tape capacity than the real capacity. Amanda will hit EOT and end the day's dumping and taping. Anything remaining will autoflush to tomorrows tape. Occasionally, will a little too much for each day accumulating on the holding disk, you will have to amflush to tape those dumps. You also should, as you mention, alter your reserve value. You will not want to go into any "degraded mode" situation without some space available for level 0 dumps. BTW your phrasing "reserve xx% for full backups" is slightly off. The distinction is space that can be used for any level backup and space that can be used only for incrementals. It is the latter, incremental only, that you reserve (defaulting to 100% in degraded mode). The rest can be used for any levels until reaching the reserve %. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Amanda cygwin client behind a firewall
McGraw, Robert P. wrote: Is anyone else backuping up an amanda cygwin client, where the cygwin client sits behind a firewall and the server sits on the outside of the firewall? I have cygwin clients but on the same side of the firewall. Anyway, the configuration: amanda server -> firewall -> cygwin amanda client is the same as amanda server -> firewall -> linux amanda client What cygwin does is run your programs as if you have a linux box. And linux boxes on the other side of the firewall I have. Firewall rules, for amanda, refer to tcp and udp - no matter if you have a linux box client or a cygwin one. I need to ask a few questions on your firewall settings. So ask, let's see if I can help... ;-) Bye! Robert
Backup for specific files
Hi, I am trying to take the backup for .log/.txt/executable file name. But the planner is not able to provide the estimations. I observed that only we can take the backup for the directories. Why this one is happening? Please provide the details is there any restrictions to provide to take the backup for the file type? Please clarify these doubt. Thanks & Regards, Silpakala __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: planner: disk xxx:/, estimate of level N failed
Hi, | sendsize[11906]: argument list: /bin/tar --create --file /dev/null --directory /home/p72 --one-file-system --numeric-owner --listed-incremental /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_3.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendsize._home_p72_orig.20060713004504000.exclude --files-from /tmp/amanda/sendsize._home_p72_orig.20060713004504000.include | sendsize[11906]: time 1.574: /bin/tar: Unexpected field value in snapshot file | sendsize[11906]: time 1.574: /bin/tar: Error is not recoverable: exiting now | sendsize[11906]: time 1.575: . | sendsize[11906]: estimate time for /home/p72/orig level 3: 0.005 | sendsize[11906]: no size line match in /bin/tar output for "/home/p72/orig It looks like the /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_3.new file is corrupted. This file is a copy of /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_2. Do you have free space in /var/lib/amanda/gnutar-lists/ ? Maybe it's a bug in tar? which tar version? Jean-Louis
Re: Ran a Tapetype for LTO-3 if anyone is interested
On Wed, Jul 12, 2006 at 06:28:24PM -0700, Tanniel Simonian wrote:
> I am unsure why my tape is half the speed but almost 40 gigs more than the
> others in the Amanda Wiki. My tapes are Imation Ultrium LTO 3 tapes. Maybe
> they are a little longer?
Tanniel,
Check your bus, we installed a new HBA (host bus adapter) in our
server in order to get proper performance, between scsi, lvd and
other issues you really do need to make sure you've installed the
proper supporting HW.
> Amtapetype was executred with the device /dev/st0, I do not think this
> would make a difference, or can it? Also SCSI generic support was not
> available at the time.
>
> Now that I have everything from the barcode reader working to the tapes
> labeled, I will run the tapetype again. I also have SCSI generic enabled
> and plan to run tapetype with the /dev/nst0 device.
>
> I will cut and paste the complete console message after the job is
> complete if it comes out different. I will use the same tape that I used
> to run the original tapetype too.
>
> After all, I too am wondering why I got more space but half the speed. I'd
> rather have the reverse.
>
> Tano
>
> On Wed, July 12, 2006 12:18 am, Paul Bijnens wrote:
> > On 2006-07-11 19:46, Tanniel Simonian wrote:
> >> Amanda Group
> >> I ran the amtapetype from Amanda 2.5.0p2 last night, took about 6 hours
> >> to
> >> complete the estimate:
> >>
> >> Model: Quantum Superload 3 LTO-3 16 Tape Library.
> >>
> >> define tapetype QS3LTO-3 {
> >> comment "Quantum Super Loader 3 LTO-3 16 tape library"
> >> length 448369 mbytes
> >> filemark 6403 kbytes
> >> speed 37739 kps
> >> }
> >>
> >> I ran amtapetype on /dev/st0 on a debian Testing distribution.
> >> SCSI interface VHDI 68 Pin Ultra 160 connector running on a Adaptec
> >> 39160
> >> 2 channel SCSI 160 PCI-X interface. Server DELL PE 850 Dual Core P4 3.4
> >> GHZ 4 GB RAM
> >
> > Wow. You got 440 Gbyte on a 400 Gbyte tape???
> > But your speed is about half what others got...
> >
> > Compare this to:
> >
> > http://wiki.zmanda.com/index.php/Tapetype_definitions#LTO_Ultrium_3_with_400.2F800_Gbyte_tapes
> >
> > I'm curious about the cause these significant differences!
> >
> > (Not owning an LTO3 -- just curious.)
> >
> > --
> > Paul Bijnens, xplanation Technology ServicesTel +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, *
> > * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
> > * ... "Are you sure?" ... YES ... Phew ... I'm out *
> > ***
> >
> >
>
>
---
Brian R Cuttler [EMAIL PROTECTED]
Computer Systems Support(v) 518 486-1697
Wadsworth Center(f) 518 473-6384
NYS Department of HealthHelp Desk 518 473-0773
Re: Problems using amanda to backup SMB shares
* Jon LaBadie <[EMAIL PROTECTED]> [2006:07:12:17:49:06-0400] scribed:
> On Wed, Jul 12, 2006 at 09:31:09AM -0500, Michael D Schleif wrote:
> > * Jon LaBadie <[EMAIL PROTECTED]> [2006:07:12:00:09:07-0400] scribed:
> >
> >
> > > When asked to, and if run by root, they record the date and
> > > time and level of the dumps in a file /etc/dumpdates. This
> > > file then can be used by dump in the future to decide what
> > > needs backing up at various dump levels.
> > >
> > > Tar does not have this built-in, so amanda mimics it in
> > > /etc/amandates.
> >
> > My point is, on _my_ amanda server, that files does NOT exist:
> >
> > # sudo ls /etc/ama*
> > Password:
> > /etc/amandahosts /etc/amandapass
> >
> > /etc/amanda:
> > DailySet1 crontab.amanda
> >
> > What am I missing?
>
> On each client that is using tar for dumping you need
> /etc/amandadates, owned by client's "amandauser/group",
> rw by user&group
>
> If your server is also a client, then you need that file.
My point is that I do NOT have any /etc/amandates on server, NOR
clients. Although, Olivier Nicole states that I can simply create my
own, and amanda will use it; I remain unclear about this file, because I
do NOT find it documented anywhere ?!?!
> amandahosts should be ".amandahosts" and it should not
> be in /etc, but in the home directory of amandauser.
Well, Debian uses /etc/amandahosts on server and clients:
# dpkg -S /etc/amandahosts
amanda-common: /etc/amandahosts
> BTW in your line:
>
> > # sudo ls /etc/ama*
>
> Do you really need to sudo to execute ls on the /etc dir?
> Particularly if you are already running as root ('# ' prompt).
Actually, I am NOT root; and I have a more complex prompt, which I edit
to simplify my posts:
[EMAIL PROTECTED]:~
# sudo ls -al /etc/amanda*
-rw--- 1 backup backup 182 Oct 8 2005 /etc/amandahosts
-rw--- 1 backup backup 455 Jul 29 2004 /etc/amandapass
/etc/amanda:
total 12
drwxrwx--- 3 backup backup 1024 May 27 11:36 .
drwxr-xr-x 149 root root 7168 Jul 13 03:11 ..
drwxrwx--- 3 backup backup 3072 Jul 13 05:49 DailySet1
-rw-rw 1 backup backup 490 Nov 2 2003 crontab.amanda
Thank you, for your participation in these issues ...
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
signature.asc
Description: Digital signature
Amanda cygwin client behind a firewall
Is anyone else backuping up an amanda cygwin client, where the cygwin client sits behind a firewall and the server sits on the outside of the firewall? I need to ask a few questions on your firewall settings. Thanks Robert _ Robert P. McGraw, Jr. Manager, Computer System EMAIL: [EMAIL PROTECTED] Purdue University ROOM: MATH-807 Department of MathematicsPHONE: (765) 494-6055 150 N. University Street FAX: (419) 821-0540 West Lafayette, IN 47907-2067 smime.p7s Description: S/MIME cryptographic signature
Re: planner: disk xxx:/, estimate of level N failed
On Wed, 12 Jul 2006, Frank Smith wrote: > In the last few days I've started seeing a couple of messages like > the above in the NOTES section of my daily reports. The DLEs in > question do get backed up, but it is a level 0 each night. Originally > it was just one server, now it is two. Interesting. I'm seeing the same since July 8, except that for me it's the estimates of level 2 or 3 that fail, so Amanda falls back to level 1 or 2, filling my (now too small) vtapes using the same (too low) level each night in a row :-( >Both are running 2.5.0p2-1 Debian etch packages, one is x86, the Same for me. > other is arm. A third amd64 machine is still working fine so far. > The appearance of the errors may have coincided with package updates, > but I'm not sure (although they have been 2.5.x for awhile). >Since I've been running Amanda for years, my first thought was > just to check the /tmp/amanda/*debug files, but was surprised to > find that those files don't exist on any of the 2.5.0 machines, > all that is in /tmp/amanda are selfcheck*exclude, sendbackup*exclude, > and sendsize*exclude files. They're in /var/log/amanda This is what I see: | endsize[11906]: time 1.363: calculating for amname '', dirname '/home/p72', spindle 1 | sendsize[11906]: time 1.363: getting size via gnutar for /home/p72/orig level 0 | sendsize[11906]: time 1.365: spawning /usr/lib/amanda/runtar in pipeline | sendsize[11906]: argument list: /bin/tar --create --file /dev/null --directory /home/p72 --one-file-system --numeric-owner --listed-incremental /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_0.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendsize._home_p72_orig.20060713004503.exclude --files-from /tmp/amanda/sendsize._home_p72_orig.20060713004503.include | sendsize[11806]: time 1.367: waiting for any estimate child: 1 running | sendsize[11906]: time 1.495: Total bytes written: 1435545600 (1.4GiB, 11GiB/s) | sendsize[11906]: time 1.496: . | sendsize[11906]: estimate time for /home/p72/orig level 0: 0.130 | sendsize[11906]: estimate size for /home/p72/orig level 0: 1401900 KB | sendsize[11906]: time 1.496: waiting for /bin/tar "/home/p72/orig" child | sendsize[11906]: time 1.496: after /bin/tar "/home/p72/orig" wait | sendsize[11906]: time 1.496: getting size via gnutar for /home/p72/orig level 2 | sendsize[11906]: time 1.510: spawning /usr/lib/amanda/runtar in pipeline | sendsize[11906]: argument list: /bin/tar --create --file /dev/null --directory /home/p72 --one-file-system --numeric-owner --listed-incremental /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_2.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendsize._home_p72_orig.20060713004504.exclude --files-from /tmp/amanda/sendsize._home_p72_orig.20060713004504.include | sendsize[11906]: time 1.548: Total bytes written: 1435545600 (1.4GiB, 43GiB/s) | sendsize[11906]: time 1.549: . | sendsize[11906]: estimate time for /home/p72/orig level 2: 0.039 | sendsize[11906]: estimate size for /home/p72/orig level 2: 1401900 KB | sendsize[11906]: time 1.549: waiting for /bin/tar "/home/p72/orig" child | sendsize[11906]: time 1.549: after /bin/tar "/home/p72/orig" wait | sendsize[11906]: time 1.549: getting size via gnutar for /home/p72/orig level 3 | sendsize[11906]: time 1.569: spawning /usr/lib/amanda/runtar in pipeline | sendsize[11906]: argument list: /bin/tar --create --file /dev/null --directory /home/p72 --one-file-system --numeric-owner --listed-incremental /var/lib/amanda/gnutar-lists/anakin_home_p72_orig_3.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendsize._home_p72_orig.20060713004504000.exclude --files-from /tmp/amanda/sendsize._home_p72_orig.20060713004504000.include | sendsize[11906]: time 1.574: /bin/tar: Unexpected field value in snapshot file | sendsize[11906]: time 1.574: /bin/tar: Error is not recoverable: exiting now | sendsize[11906]: time 1.575: . | sendsize[11906]: estimate time for /home/p72/orig level 3: 0.005 | sendsize[11906]: no size line match in /bin/tar output for "/home/p72/orig" | sendsize[11906]: . | sendsize[11906]: estimate size for /home/p72/orig level 3: -1 KB | sendsize[11906]: time 1.575: waiting for /bin/tar "/home/p72/orig" child | sendsize[11906]: time 1.575: after /bin/tar "/home/p72/orig" wait | sendsize[11906]: time 1.575: done with amname '/home/p72/orig', dirname '/home/p72', spindle 1 | sendsize[11806]: time 1.576: child 11906 terminated normally If I run the tar commands by hand (but that's _after_ the amanda run), I get: | Total bytes written: 1435545600 (1.4GiB, 45GiB/s) | Total bytes written: 1435545600 (1.4GiB, 42GiB/s) | Total bytes written: 20480 (20KiB, 4.0MiB/s) I.e. all succeeded. >It's not critical, theses are my home machines and I have the > space to handle nightly level 0s, but I had been considering an > upgrade of my work machines to 2.5 from 2.4.5 and am now concerned > that this migh
Exclude list entries
Dear all, I've now configured an exclusion list for use with Amanda. At first I used these entries: *.ora *.dbf *.dmp *.dmp.gz* but then I re-read the Amanda documentation, which states: "When AMANDA attempts to exclude a file or directory it does so relative to the area being archived. For example if /var is in your disklist and you want to exclude /var/log/somefile, then your exclude file would contain ./log/somefile" So I've changed the entries to these: ./*.ora ./*.dbf ./*.dmp ./*.dmp.gz* amcheck config reports no errors or problems with either set of entries. I really just want to confirm whether or not I could have used the entries without ./ and what the difference between the different sets of entries would be. Thanks very much. Joe -- View this message in context: http://www.nabble.com/Exclude-list-entries-tf1936459.html#a5305717 Sent from the Amanda - Users forum at Nabble.com.
Re: backing up to DVD-Rs
On Thursday 13 July 2006 09:20, Ross Vandegrift wrote: > On Wed, Jul 12, 2006 at 06:31:52PM +0100, Anne Wilson wrote: > > On Wednesday 12 July 2006 18:17, Ross Vandegrift wrote: > > > Make a holding area, and use dump with a tape size of just slightly > > > less than the DVD-R size. Tell dump to generate manifests and quick > > > file access data. > > > > > > Then, all you have to do is burn each dump file to a DVD-R in > > > pre-prepared mode (check man growisofs for details on this) and > > > burn/store the index/QFA data somewhere. > > > > Would you like to amplify this, please? > > Sure. Assume that you've got /dev/sda1 that you'd like to backup and > you'll store the images in /holding. Then it goes a little something > like this: > > # cd /holding > # dump -0uy -A MANIFEST -B 4403200 -Q QFA /dev/sda1 -f > disc1,disc2,disc3,... ... (wait for dump to dump the filesystem) > # growisofs -dvd-compat -Z /dev/dvd=disc1 > ... (burn all the images) > > The dump command generates files named "disc1", "disc2", etc (you may > need more than three depending on your filesystem), as well as a > restore index called MANIFEST and quick file access info named QFA. > You can do an incremental by changing the "-0" to some higher integer. > You may need to twiddle with -B, the size param. I don't remember > exactly how large it can be. > > > Then, restoring from DVD looks like this: > > # cd /destination > # restore -A MANIFEST -Q QFA -i -f /dev/dvd > ... (restore as usual, inserting discX when asked for volume X) > > > That's all there is to my personal backup system. It has one *major* > flaw: backups are not automated the way they are with Amanda. I guess > if you're burning to DVD, you have to manually interact anyhow. But > as a result, I have only ever done two complete backups of my > system... > > On the other hand, I did use such a backup to recover from a > catastrophic disk crash and it worked very well. Thanks for the explanation. The system I'm using does the automatic backup to hard disk, from where I can record to DVD when convenient. Slot 14, for instance, has four and a bit DVDs-worth of Level 0 /home. I have assumed that I need to burn everything in Slot 14 to disk, then the Slot 15 and 16 /home incrementals to bring it up to date. Is there something else I should be doing? Anne pgp82wQddJP3t.pgp Description: PGP signature
Re: planner: disk xxx:/, estimate of level N failed
On 2006-07-13 05:29, Frank Smith wrote: Since I've been running Amanda for years, my first thought was just to check the /tmp/amanda/*debug files, but was surprised to find that those files don't exist on any of the 2.5.0 machines, all that is in /tmp/amanda are selfcheck*exclude, sendbackup*exclude, and sendsize*exclude files. It's not critical, theses are my home machines and I have the space to handle nightly level 0s, but I had been considering an upgrade of my work machines to 2.5 from 2.4.5 and am now concerned that this might be a bug that needs fixing before I upgrade. The estimate error may be just a Debian package thing, either in the Amanda package or possibly in tar, but evidently the debug files have been missing longer than the estimate error. I believe Debian has put the debug directory somewhere else. Try: amadmin xx version | grep DBG -- Paul Bijnens, xplanation Technology ServicesTel +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, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
Re: backing up to DVD-Rs
On Wed, Jul 12, 2006 at 06:31:52PM +0100, Anne Wilson wrote: > On Wednesday 12 July 2006 18:17, Ross Vandegrift wrote: > > Make a holding area, and use dump with a tape size of just slightly > > less than the DVD-R size. Tell dump to generate manifests and quick > > file access data. > > > > Then, all you have to do is burn each dump file to a DVD-R in > > pre-prepared mode (check man growisofs for details on this) and > > burn/store the index/QFA data somewhere. > > > Would you like to amplify this, please? Sure. Assume that you've got /dev/sda1 that you'd like to backup and you'll store the images in /holding. Then it goes a little something like this: # cd /holding # dump -0uy -A MANIFEST -B 4403200 -Q QFA /dev/sda1 -f disc1,disc2,disc3,... ... (wait for dump to dump the filesystem) # growisofs -dvd-compat -Z /dev/dvd=disc1 ... (burn all the images) The dump command generates files named "disc1", "disc2", etc (you may need more than three depending on your filesystem), as well as a restore index called MANIFEST and quick file access info named QFA. You can do an incremental by changing the "-0" to some higher integer. You may need to twiddle with -B, the size param. I don't remember exactly how large it can be. Then, restoring from DVD looks like this: # cd /destination # restore -A MANIFEST -Q QFA -i -f /dev/dvd ... (restore as usual, inserting discX when asked for volume X) That's all there is to my personal backup system. It has one *major* flaw: backups are not automated the way they are with Amanda. I guess if you're burning to DVD, you have to manually interact anyhow. But as a result, I have only ever done two complete backups of my system... On the other hand, I did use such a backup to recover from a catastrophic disk crash and it worked very well. -- Ross Vandegrift [EMAIL PROTECTED] "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
Re: amrecover "Tape is not a dump tape" but amrestore works?
Jon LaBadie wrote: On Wed, Jul 12, 2006 at 11:03:38AM -0400, Julian C. Dunn wrote: On Wed, 12 Jul 2006, Jon LaBadie wrote: So whatever was fed by amrecover to the restore program did not appear to be created by the corresponding dump program. Do you use dump/restore in your amanda dumptypes or gnutar? I use dump/restore. I was trying to restore files from babelfish (a FreeBSD 6.1 box) on the tape server aphrodite (a FreeBSD 4.9 box). One would think the dump/restore utilities would be the same between versions though? What filesystems have you got on babelfish. FreeBSD 5.0 and later will use UFS2 as the default filesystem type, before this it was plain old UFS. hance the dump/restore programs will different, which is prob why it's not working. -- Martin Hepworth Senior Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote confirms that this email message has been swept for the presence of computer viruses and is believed to be clean. **
