Re: deleting contents of vtapes after backups
On Tue, Jun 08, 2004 at 01:29:27PM +0200, Axel Scheepers (thuis) wrote: >I installed amanda on my local network and it's doing fine. I've got 2 >configs, one daily which backups to a set of 5 vtapes of 700mb each to >burn to cdr, and one weekly full which backups to a set of 250 vtapes of >4GB each to burn to DVD. OK... but a TB of backups on vtapes sounds like rather a lot to me >The weekly-dvd config has these settings in it: >dumpcycle 0 >#runspercycle 4 Ummm... the "#" indicates a comment line in amanda.conf. >This only creates full backups of the files. I wonder however, I do not >have the space for all these 250 vtapes, could I delete them after >backing up? ??!? Well, it's your data, and your config; you can destroy your backups & lie to amanda if you want to. I rather doubt that this will make your life easier, though. >I was thinking of deleting only the data in these dirs, which if I'm not >mistaken let's me reuse these tapes whenever I get close to nr.250 (with >amadmin reuse tapelabels), while only using the space of do many I have >room for. I think you are likely to be a lot better off telling amanda the truth about how many backups to remember. At least that way, she's less likely to tell someone that in order to restore certain data, yshe needs to read data from a backup that you have destroyed. I'd think that would be fairly frustrating for all concerned. I certainly would not do that intentionally, and I hope I wouldn't do it accdentally, either. Peace, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: Archiving With Amanda?
On Fri, May 28, 2004 at 03:03:42PM -0400, Eric Siegerman wrote:
>
>(Simply amdumping twice would not make *identical* copies, since
>the first run would change the files' last-access timestamps, if
>nothing else.)
Changing the last-access time of a file is only an issue for mechanisms
that open the files in question. For example, tar opens (individual)
files that it reads. On the other hand, {,ufs}dump does not: the thing
it opens is a file system, so it does not change inode contents at all.
That said, there exist other reasons the product of another backup
process is unlikely to be an identical copy of the first.
IIRC, someone posted a note about how he ran an amdump, and as chunks
were written to the holding disk (well, before the chunks were taped &
unlinked), he made another link to each file, so after the first taping,
the files in the holding disk were still there, and an amflush run created
another tape with the same data.
Peace,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Re: excluding while backing up Windows box
On Wed, Mar 17, 2004 at 10:09:18PM +0100, Stefan G. Weichinger wrote: >I have repeatedly (is that english really ...?) posted questions about >this on the samba-list without replies. Yes, "repeatedly" is a perfectly good English word, and you used it in an appropriate context. :-} [The language is a little too flexible for its own good sometimes -- to say nothing of the "good" of those who use it. I am reminded of Victor Borge's line: "It's *your* language; I'm just trying to *use* it!"] Peace, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: Allways Level 0 on one tape?
On Tue, Feb 24, 2004 at 09:26:00AM -0500, Joshua Baker-LePain wrote: >On Tue, 24 Feb 2004 at 2:04pm, Tom Brown wrote >> Is it possible to have amanda allways do a level 0 to a particular tape? >> >> say i have 7 tapes i would like the normal run on 6 of them shich may >> include level 0's but when it comes to one tape allways do a level 0 to this >> tape? >> >> Is that possible? > >The only way I can think of offhand to do it would be semi-manually. You >could run a script (in cron, even) to check the output of 'amadmin $CONFIG >tape'. If the output is the tape you want level 0s on, run 'amadmin >$CONFIG force' for each entry in your disklist. The thought that occurs to me -- assuming(!) that I properly understand the requirement -- would be to create a second Amanda configuration, in which all backups are level 0s, and use that configuration when the tape in question is to be written. This may require a bit of "juggling" depending on the number of tapes, frequency of backups, and the like. [When I was at Whistle, I used a "normal" Amanda configuration 6 days of the week; the remaining day, I used a different configuration, using the same pool of tapes, that did a level 0 backup of everything, but did not record the information (in amandadates) -- thus, these level 0 backups would not be used as a "base" from which to create incrementals. I would then place the full backups & the documentation for them in a canister to be picked up for off-site storage. We had a set of 3 such canisters; most of the time, one canister was on-site (and empty), while the other two were off-site. (It would be Very Bad to need to use the off-site facility, only to find that the only backup of some critical data didn't make it. Thus, I tried to improve the odds by keeping the previous weeks' full backup there, as well.) Even if a courier had one canister, there should be one in safe-keeping at all times. These numbers could be adjusted, certainly: 3 would be the minimum.] Peace, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: Help configuring a Breece Hill Q7
On Mon, Feb 23, 2004 at 11:20:45AM -0500, jlm17 wrote: >How do I configure amanda to handle a Breece Hill Q7 tape changer? It >has two disks and 28 tape slots. I am guessing that I need to set >tpchanger to "chg-scsi" but how do I tell it what the tape changer >device is, and about both of the drives and the number of tapes etc.? As Joshua pointed out, it would help to mention something about the OS with which you're working. I have not used that model, but I do have a different (re-badged) Breece Hill device working under FreeBSD-STABLE, using the chg-chio changer. I needed to make changes in order for it to work: * To the chg-chio Perl script itself -- I sent the patches that I found appropriate in to amanda-hackers a couple of months ago. * To /usr/src/sys/cam/scsi/scsi_ch.c; it seems that (per one of the FreeBSD SCSI developers who has way more clue than I do) that the device was lying about how big a buffer would be required to hold the result from a SCSI "inquiry" request. The patch was really gross: I just multiplied the amount of buffer (as calculated) by 4 before the malloc() was done. (If someone really wants this patch, please mail me privately -- this isn't an amanda issue.) Peace, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: NT backup
On Tue, Dec 23, 2003 at 02:07:07PM -0500, jessica blackburn wrote: > > i got the samba working so i can talk with the ms box. now i'm trying > to get the amanda win32 working to try and backup the system. i am > connecting to the MS box but i am getting an error that i can't seem to > figure out when i'm running amcheck. > > > -bash-2.05b$ /usr/sbin/amcheck DailySet1 > Amanda Tape Server Host Check > > Amanda Backup Client Hosts Check > > ERROR: NAK hccdevelop03: execute access to > "/usr/amanda/libexec/selfcheck" denied > Client check: 2 hosts checked in 0.135 seconds, 1 problem found > the directory setup on the MS machine does not contain anything called > selfcheck. This, I believe, is the root of the above-reported problem. > do i need this here or should it be running from my linux > machine? also, on my MS maching i do not have a folder under usr called > lib. again is this a problem. Well, if you want the MS box's "selfcheck" to work, you do need a nominally-functional "selfcheck" on that box. It (selfcheck) is not necessary for the backups themselves to work, though. > Thanks for all the help. I'm just getting started with this and i tend > to get stuck A LOT!!! The MS/win32 stuff tends to be a lot more confusing than more reasonable system are. :-} Peace, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: Win32 client (was: Re: Amanda GUI)
On Wed, Nov 05, 2003 at 02:36:46PM +0100, JC Simonetti wrote: > On Wed, 5 Nov 2003 04:52:33 -0800 > David Wolfskill <[EMAIL PROTECTED]> wrote: > > I wasn't aware that the Win32 environment was sufficiently "special" > > that tar archives were unportable between that and normal (UNIX) > > environments. > It's the reason of the existence of the WinTar software :) Oh. I had (perhaps naively) thought that it was merely a win32/NT/...? port of a more standard tar > > Well, I suppose it might be, if it were small enough to fit in the > > available space on the Windows box, and if someone who had a clue about > > the Windows environment (i.e., not me) did it. But it's a (Win32) tar > > archive for the entire "C:" drive. > Whoops... Try a smaller tar to make your tests... Well, I suppose any sub-tree would be somewhat smaller, but I have no idea how Microsoft spells "du". > I did not use amrecover for my restorations, but just amrestore. Why? Because in my > backup architecture, I d not want to restore to data directly on the client but I > restore them on the backup server then push them on the client. > And as WinTar and GnuTar are different, I was just able to extract the dd image from > the tape with amrestore and push these data on the Win32 server, and over there > untar them. > But I was backing up small data, something les than 5 Gb, so I was able to have on > my Windows box the tar and the untar data simultaneously, right :) Ah. Well, nearly anything that is done around here involving a Microsoft platform will need to be done by someone other than me: they seem to be remarkably unreliable around me. (They probably know what I think of them) > Concerning development on Win32 architectures, you have Dev-C++ > (http://sourceforge.net/projects/dev-cpp/) : a free software IDE compiler under > Windows. Well, for whoever does the development, that might be useful; thanks. > Personally I don't like the Win32 client since it is based on a CVS snapshot of > Amanda from august 2001 : so old isn't it?! Understood. I believe that my employer would be willing to pay someone to re-do that work, with a more recent version of the source. > Maybe a future development of this client should only be libraries to interface the > *nix version of Amanda under Win32, maybe real libraries or patches to apply on the > sources, but something that would be generic and not applied on a particular version > and just on this version. Maybe in the longer term; for now, we just want something that actually works. > The 2 other solutions are : > 1. Samba backup using "smbclient" on the Linux Amanda server: simple but you do not > backup NT file rights (well... see some messages above in the mailing-list, someone > sent a little script to backup the rights) Yes, I know of this. However, in our environment, it is not an acceptable approach. > 2. Cygwin and the Amanda source code: very functional but you have to install a > Linux emulator on your Windows box... I don't like the idea (what would you say if I > told you that you have to install a Windows emulator on your BSD to backup your BSD?) Right; I expect that Cygwin will be involved, but only for development. We are trying to minimize the impact on clients' machines. Thanks again, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: Win32 client (was: Re: Amanda GUI)
On Wed, Nov 05, 2003 at 10:26:37AM +0100, JC Simonetti wrote:
> [...]
> > But in the testing so far, we're finding some odd results:
> > * The actual program that the Win32 client uses to do the backups
> > appears to be an NT port of tar. But trying to restore a file
> > made from that backup on a FreeBSD system generates a message saying
> > that the file does not look like a tar archive.
> Sure... It's a Win32 tar archive...
I wasn't aware that the Win32 environment was sufficiently "special"
that tar archives were unportable between that and normal (UNIX)
environments.
> A tar archive includes: data of the file and data related to the file: name,
> rights... And rights are completely different between *nix and Windows...
OK; I'll take your word for it.
> Take your tar on a Windows box and untar it: it will be successful.
Well, I suppose it might be, if it were small enough to fit in the
available space on the Windows box, and if someone who had a clue about
the Windows environment (i.e., not me) did it. But it's a (Win32) tar
archive for the entire "C:" drive.
> > Also, "ls" showed each directory twice -- once as a directory; once as
> > a regular file.
> Which ls? In amrecover?
Yes.
> > * Trying to use the "amrestore" on the Win32 side, the "ls" command
> > doesn't seem to work.
> amrestore or amrecover? amrestore just dd's out the tape and, if you want, make a
> grep on the output. There's no ls...
Right; sorry: I screwed up. I meant "amrecover".
> > At some point, I would like my employer to contribute some resources
> > toward making this version of the amanda client solid enough to install
> > from the directions and run. This may include paying someone to
> > implement "selfcheck," for example, as well as other parts of the Win32
> > client that need attention. Speaking only for myself, I would be less
> > interested in a GUI for any of this, but that's just me.
> When I tested the Win32 client, I needed a selfcheck. This was for production
> systems, not workstations (so you may find my solution not useful). My selfcheck was
> something like:
> int main() {
> return 0;
> }
That's fine (and resembles /usr/src/usr.bin/true/true.c, without
the BSD copyright that the version I use has), but I have no Win32
development environment. At the rate things are going, we're looking
for some help in doing some work in such an environment so we can
create executables that will actually work; I have no reason to
believe that a physical presence here (in Fremont, California) is
especially necessary.
Thanks,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Re: Win32 client (was: Re: Amanda GUI)
On Tue, Nov 04, 2003 at 09:35:24AM -0800, David Wolfskill wrote: > > [Re: win32 amanda client from sourceforge) > > But in the testing so far, we're finding some odd results: > > > > * Trying to use the "amrestore" on the Win32 side, the "ls" command > doesn't seem to work. > > At some point, I would like my employer to contribute some resources > toward making this version of the amanda client solid enough to install > from the directions and run. This may include paying someone to > implement "selfcheck," for example, as well as other parts of the Win32 > client that need attention. Speaking only for myself, I would be less > interested in a GUI for any of this, but that's just me. Has anyone got "amrecover" for a file backed up via the win32 client to actually work? If so, how? If not, it is possible that my employer would be willing to pay someone to bring it sufficiently up-to-date that it actually works. (Since the backup image is created OK, we are expecting that this ought not be a huge amount of work for someone with a reasonable ability & willingness to develop in/for the win32 environment.) It would be Nice(tm) if, aas an additional result, it would be possible to do an amrecover from the UNIX side against a backup created in the win32 side and have a reasonable expectation that some arbitrary set of the files could be restored. [I note that I was given a pointer to "star", which may well help with the latter task, but does nothing, as far as I know, for restoring files in the win32 environment.] Thanks, david -- David H. Wolfskill [EMAIL PROTECTED]
Win32 client (was: Re: Amanda GUI)
On Tue, Nov 04, 2003 at 09:09:34AM -0500, Bort, Paul wrote: > > Perhaps I find the time to implement something like this in the next > > weeks...but to be honest before having a GUI for amanda I > > would prefer seeing a windows client *duck* :) > No need to duck! Lots of people would like this, just search for 'SAMBA' > in the mailing list archives. I looked at this "back in the day", and it > breaks down to two parts: A tar clone that can backup and restore files > under NT, and amandad. There are instructions for building amandad under > Cygwin, and there was a SourceForge project for an AMANDA client that had > (IIRC) 90% of a working NT tar, with ACLs. If you combine the two with a > little elbow grease, you could have a Windows client in an afternoon. If > you need to do it without a full Cygwin installation, you could probably > just copy the right files and registry entries out of an existing one. > (I know you can run Cygwin's ssh.exe with just one other DLL, I think it's > cygwin1.dll.) I have had recent exposure to this My employer seeks to provide "backup" services for clients, some of whom evidently have data that they value enough for it to be backed up, but so little that they have chosen to host it on a Microsoft platform. (Yes, I confess that I find this self-contradictory.) And for many (most? all?) of such cases, placing the data on a CIFS/SMB/Samba "share" is (apparently) not acceptable. After seeing the price tag for a proprietary product that would support both the systems I care about (FreeBSD) and the Microsoft environments -- as well as seeing the ugly messages about data overruns from the proprietary product (vs. the clean output in the logs from running amanda) -- we decided to put a bit more effort into coercing the win32 amanda client to work. It's our intent to put together some documentation telling how to make this work (for some plausible definition of "work"), if that would be useful. But in the testing so far, we're finding some odd results: * The actual program that the Win32 client uses to do the backups appears to be an NT port of tar. But trying to restore a file made from that backup on a FreeBSD system generates a message saying that the file does not look like a tar archive. Also, "ls" showed each directory twice -- once as a directory; once as a regular file. * Trying to use the "amrestore" on the Win32 side, the "ls" command doesn't seem to work. At some point, I would like my employer to contribute some resources toward making this version of the amanda client solid enough to install from the directions and run. This may include paying someone to implement "selfcheck," for example, as well as other parts of the Win32 client that need attention. Speaking only for myself, I would be less interested in a GUI for any of this, but that's just me. Peace, david -- David H. Wolfskill [EMAIL PROTECTED]
Re: Strange dump summary...
>Date: Fri, 2 Feb 2001 11:51:37 -0800 (PST) >From: smallA <[EMAIL PROTECTED]> >/usr/local/libexec/sendsize: version 2.4.1p1 >calculating for amname '/etc', dirname '/etc' >sendsize: getting size via dump for /etc level 0 >sendsize: running "/sbin/dump 0sf 1048576 - /etc" >running /usr/local/libexec/killpgrp > DUMP: Date of this level 0 dump: Thu Feb 1 23:45:01 2001 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/hda9 (/ (dir etc)) to standard output > DUMP: Label: none >/dev/hda9: Permission denied while opening filesystem Is the amanda user a member of a group that has read access to the raw disk device? Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: amanda 2.4.2
>From: "Patrick M. Hausen" <[EMAIL PROTECTED]> >Date: Mon, 29 Jan 2001 19:49:46 +0100 (CET) >Doesn't installing Amanda from /usr/ports/misc/amanda24 work for you? I started with amanda from "ports" back in '98, but it became rather too awkward to ensure that the Solaris boxen also had amanda configured the same way. And I migrated to 2.4.2p1 well before a "port" was available for it. >The recommended way to install software on a FreeBSD system is using >the ports collection. Well, I find the FreeBSD "ports" system a curious combination of convenience and frustration, largely, no doubt, because I'm far more accustomed to obtaining the sources for software, configuring, and building it. I haven't learned enough about the "ports" system to be able to have anywhere near as much control as easily as I do with the old-fashioned mechanism I'm used to. For cases where I want things installed the same way the port maintainer did them, the "ports" are very nice -- and that's the majority of cases. But in the case of amanda, especially in a heterogeneous environment, I found it very awkward... especially when I was trying out some of my own patches (for example). And given the present state of amanda's development, where a great deal is determined prior to compilation (at configuration time), I am reluctant to recommend any approach for installing amanda that does not expose the installer to the configuration process in all its detail. (Witness the issues brought forth by folks who install amanda "RPMs" on Linux systems, for example.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: amanda 2.4.2
>Date: Mon, 29 Jan 2001 18:02:38 + >From: Clem Kumah <[EMAIL PROTECTED]> >I have decided to upgrade amanada 2.4.1p1 to 2.4.2 >When I try to do a make command I get the following error: >make: don't know how to make amoverview. Stop >*** Error code 1 >I seem to recal that it needs gnu make. Is this correct, and where can I >get a copy? >I am runing it on a freebsd 4.2-Release It does not need GNU make (gmake; see /usr/ports/devel/gmake), although using gmake appears to work. It needs a working (as in "not broken") make. Unfortunately, the PR that I filed with the FreeBSD folks (http://www.freebsd.org/cgi/query-pr.cgi?pr=23328) doesn't appear to have received a great deal of attention from those necessary to get the matter addressed. If you would follow-up on that PR, to let folks knwo that others are being affected, I would appreciate it. In the mean time, someone else in the FreeBSD community came up with some patches against FreeBSD-CURRENT to fix the problem, and sent them to me. I ported them to FreeBSD 4.2-STABLE (which should be very close to -RELEASE), and both sets may be found in his PR, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24102. Summarizing: either installing GNU make (from /usr/ports/devel/gmake) and using gmake to build amanda, or patching the native FreeBSD make per http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24102 should do the trick for you. And regardless of which approach you tak, please update http://www.freebsd.org/cgi/query-pr.cgi?pr=23328 to let folks know that action to resolve this would be helpful. (If you need to modify the patches in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24102 for 4.2-R, it would be good to follow up on that, as well.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Amanda FAQ-o-matic "firewalls" entry
I used the Amanda FAQ-o-matic "firewalls" entry when I was setting up backups for a server that sits on the "untrusted" side of an internal packet filter, and found it helpful -- my thanks to those involved! However, I was just going over the filtering rules a bit, in order to clean things up both on the packet filter and on the host that is the amanda client. (And then we had a security advisory come out regarding the packet-filtering code we use, so I needed to make a patch & install the modified code -- thus providing an opportunity to do a test) Per the suggestion, I had built amanda on that client with the "--with-udpportrange=850,854" config directive. And I am running a backup of that client machine every day -- it's just tossed into the mix along with all the other machines. But in looking at the statistics for the filter rules on the internal packet filter, I see the only rules that mention my backup server are: dmz-gw[2] sudo ipfw show|grep 205.27 01550 0 0 allow udp from 207.76.204.2 850-854 to 207.76.205.27 01551 24 3282 allow udp from 207.76.204.2 10080 to 207.76.205.27 But the first rule shows that there were no instances of its conditions being matched, and the amanda client in question (at 207.76.204.2) is not permitted to send arbitrary traffic to the net where the amanda server (207.76.205.27) is. So yesterday afternoon, when I needed to re-boot the packet-filtering machine after applying the patches, I only installed the second rule, thus we now have: dmz-gw[3] sudo ipfw show | grep 205.27 01551 24 3282 allow udp from 207.76.204.2 10080 to 207.76.205.27 (And this morning's backups ran just fine, as far as that machine is concerned.) So it seems to me that either I'm missing something fairly basic, or that the rule # 1550 (in the first extract) isn't needed. Further, it's not apparent to me that the UDP port-range restriction is actually doing anything either. Does this make any sense? When it comes to relaxing firewall rules, I like to make sure I understand as clearly as possible just what is being done and why Thanks, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Re: changer for mammoth2 and EZ17
>Date: Wed, 24 Jan 2001 13:45:35 -0600 (CST) >From: Adam <[EMAIL PROTECTED]> >Does anyone know if and what changer works with the Exabyte EZ17 7 tape >changer with the mammoth2 drive? I'm not using that drive or changer, but... >We are using Freebsd Of what vintage? My amanda server is running FreeBSD eng-backup.whistle.com 4.2-STABLE FreeBSD 4.2-STABLE #0: Wed Dec 13 10:35:38 PST 2000 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ENG-BACKUP i386 >and the dmesg output for the drive is: >ahc0 rev 1 int a irq 10 on pci0:9:0 >ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs >ahc0 waiting for scsi devices to settle >(ahc0:0:0): "EXABYTE EXB-210 1.07" type 8 removable SCSI 2 >ch0(ahc0:0:0): Medium-Changer 7 slots, 1 drive, 1 picker >(ahc0:1:0): "EXABYTE Mammoth2 v02r" type 1 removable SCSI 2 >st0(ahc0:1:0): Sequential-Access density code 0x28, drive empty (Looks as if you might be running FreeBSD 3.x, perhaps?) I have: ahc1: port 0xd000-0xd0ff mem 0xf880-0xf8800fff irq 11 at device 12.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs sa0 at ahc1 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) ch0 at ahc1 bus 0 target 1 lun 0 ch0: Removable Changer SCSI-2 device ch0: 3.300MB/s transfers ch0: 7 slots, 1 drive, 1 picker, 0 portals >amtape shows when using chg-chio >... >and when using chg-scsi shows >... I don't use either changer script (since I had one I cobbled up, I continue to use it). >In the dmesg output >ch0(ahc0:0:0): ILLEGAL REQUEST asc:3b,90 Vendor Specific ASCQ >ch0(ahc0:0:0): ILLEGAL REQUEST asc:3b,90 Vendor Specific ASCQ ># chio params >/dev/ch0: 7 slots, 1 drive, 1 picker >/dev/ch0: current picker: 0 Yeah, I get that; what about "chio status"? eng-backup# chio params /dev/ch0: 7 slots, 1 drive, 1 picker /dev/ch0: current picker: 0 eng-backup# chio status picker 0: slot 0: slot 1: slot 2: slot 3: slot 4: slot 5: slot 6: drive 0: Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Re: summary details show errors but dumper stats
>Date: Wed, 24 Jan 2001 15:42:57 + (GMT) >From: Denise Ives <[EMAIL PROTECTED]> >show sda10 did its level 1 back up. So did sd10 back up with errors? It would appear that a backup image was created, and amanda stored it for you, per your request. The extent to which that image might be useful for actually performing a restore is somewhat open to question, and depending on how important/critical/... the data happen to be to you & your employers, you might want to do some sort of reality check, at the very least. I'd suggest doing the reality check well prior to a time that the data might actually be perceived to be needed. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
"amadmin balance" results vary by time of day...??!?
amanda 2.4.2 (released); last amanda run finished around 08:00 AM local time (it's a little over 7 hrs. later than that as I type). Please note the following results: eng-backup# date && amadmin Eng balance Thu Jan 18 13:48:07 PST 2001 due-date #fs orig KBout KB balance --- 1/18 Thu0 0 0 --- 1/19 Fri2 69877 31328 -99.8% 1/20 Sat 26 25574348 15972096+5.1% 1/21 Sun0 0 0 --- 1/22 Mon2 16773273 14385600-5.4% 1/23 Tue 53 35821993 15029280-1.1% 1/24 Wed 41 34201022 16119680+6.0% 1/25 Thu 26 32693191 14476512-4.8% --- TOTAL 150 145133704 76014496 15202899 (estimated 5 runs per dumpcycle) eng-backup# date && amadmin Eng balance Thu Jan 18 15:14:11 PST 2001 due-date #fs orig KBout KB balance --- 1/18 Thu2 69877 31328 -99.8% 1/19 Fri 25 25528144 15925888+4.8% 1/20 Sat1 46204 46208 -99.7% 1/21 Sun2 16773273 14385600-5.4% 1/22 Mon 53 35821993 15029280-1.1% 1/23 Tue 41 34201022 16119680+6.0% 1/24 Wed 26 32693191 14476512-4.8% --- TOTAL 150 145133704 76014496 15202899 (estimated 5 runs per dumpcycle) eng-backup# The totals look the same (to me), but it looks as if some part of amanda is making slightly different decisions on where a given file system's (full) backup is (probably?) going to go based on time of day (even though most of amanda that I recall has a "time granularity" of a day). And the notion that I would want a backup done today when I already did that is a little perplexing, too. So... does anyone use "amadmin balance", and if so, what do you get out of it? (Yes, I realize that the man page says it summarizes the distribution of full backups. But given the above -- which is but the beginning of a "backup migration" that "balance" would report between now & the time the actual backups get started -- I confess to a bit of curiousity on this Thanks, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Re: A list of implementation questions
>Date: Thu, 18 Jan 2001 15:22:02 -0500 >From: Hurf Sheldon <[EMAIL PROTECTED]> >Our present setup is Amanda-2.4.2-19990920 on an HPUX 10.2 system >backing up >a heterogeneous environment of NT, Irix, FreeBSD and HPUX systems to >an Overland 4000LX 15tape/1drive DLT. We are backing up the NT systems >via Samba. >Changes needed: >1: Move the drive to a PC based system - right now we have a FreeBSD >4.2-Stable >system on a dual 266mhz P-II ASUS P2B-D mother board and an Adaptec >2930CU SCSI adapter. OK; I'm using FreeBSD 4.2-STABLE as of 13 Dec 2000. The box doesn't have much in the way of CPU, but has 3 SCSI host adapters (one for the OS, one for holding disks, and one for the tape & changer). I'm running amanda 2.4.2 (as released... well, mostly) on it. >... >Related questions: >1: When we move the Overland to the FreeBSD PC and run amlabel, we get >errors in the system log file and the DLT goes out to lunch - we setup >an HP SureStore 2300 6 tape DDS as a test and saw some similar errors >but >after the tapes were labeled they subsided: >(ch0:ahc0:0:0:1): MOVE MEDIUM. CDB: a5 20 0 0 0 3 0 1 0 0 0 0 >(ch0:ahc0:0:0:1): ILLEGAL REQUEST asc:3b,d >(ch0:ahc0:0:0:1): Medium destination element full >ch: warning: could not map element source address 0d to a valid element >type >(sa0:ahc0:0:0:0): tape is now frozen- use an OFFLINE, REWIND or MTEOM >command to clear this state. Hmm... what changer script are you using? What happens if you issue "chio" commands directly (as a user who has "write" access to /dev/ch0)? (The commands I would use for startes would be "chio info" and "chio params".) >2: We can't directly access the NAS disks - how would we give dump >instructions >to a system that has it mounted via NFS or SMB? I thought Amanda used >tar >on Unix but a dump request to an Irix system with the NAS mounted failed >"disk /remote/nas01/2 offline on nimble". Ummm... you need to use tar, not dump. tar can read an NFS-mounted filesystem; dump cannot. >3: How can we configure amanda to do only level 0 or only incremental >backups? >We'd like to (say) run level 0 over the weekend to one tape set and >incrementals to >another, with an eye to adding a second tape machine and do level 0 to >one and >incrementals to the other. Set up a separate configuration for that. I do something like this, in that I run the "usual" backups Monday - Saturday, and then on Sunday, I run a different configuration that does record-no level 0 backups of everything; the media from this are sent off-site for 2 weeks. Much of the information is set up to be shared between the configurations (by a combination of "include" directives & symlinks). I can send more details if that's not enough (but I thought I had a fair amount of detail in a message a week ago or so). >3a: To use a second 15 tape magazine, is there a way to setup >amanda.conf to count >all 30 tapes sequentially? The problem seems to be that Amanda thinks >there is >30 slots if there are 30 tapes, so the chio routines fail. We'd like to >have it stop >the tapers, ask for the next magazine and start at slot 1 again. Sounds as if you'd need to use a custom changer script to do that, though my knowledge of the details of the stock ones is pretty limited. Starting with an existing script that comes close can be helpful. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Re: Reusing tapes
>Date: Thu, 18 Jan 2001 09:14:10 +1100 (EST) >From: Ben Elliston <[EMAIL PROTECTED]> >I am in the process of debugging my Amanda setup and wish to reuse the same >tape over and over. Short of using `mt erase' to completely erase the tape, >is there a way I can prevent Amanda from aborting because it thinks I'm >overwriting a tape from the backup set? When I was doing something similar, I found "amrmtape" sufficient. (And "mt erase" would not affect what amanda believes about the tape; it would merely disguise the fact that the tape is one that amanda had seen before.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Re: Diagnosing client-side errors
>Date: Tue, 16 Jan 2001 18:45:43 -0500 >From: "John R. Jackson" <[EMAIL PROTECTED]> >>i thought you needed to use >>/dev/sdan where n is the number of the partition >No, you don't. You may use one of these forms, give the above comments >about system configuration are taken into account: > sda (the block device name) > rsda (the "raw"/character device name) > /dev/sda (full path to the block device name) > /dev/rsda (full path to the "raw"/character device name) > /the/mount/point (file system mount point) >The exact syntax depends on the OS. And I encourage folks who are in the position of deciding which form(s) to use to consider the issue from the perspectives they are likely to have when (note lack of conditional) they need to perform a restore. For me, the answer was to use names that denote function, vs. implementation -- in the case in point, I use mount points (now; I had started with device names). And that's probably a Good Thing in my case, because some of the device names have changed with changing OS (FreeBSD) levels. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Weird illustration of peculiar interactions :-}
So a few weeks ago, I finally got around to implementing (as recorded
either here in amanda-users or in -hackers; I forget) a separate
"Offsite" configuration that runs on Sundays, and does a full backup of
everything (with "no-record"). Since I had been able to (just barely!)
run amanda with a dumpcycle of 2 days, I figured that I should normally
be able to get the full ("Offsite") backup in 2 tapes... so I defined a
runtapes value of 3.
Well, as it happened, one of the file systems I back up is hovering right
around 12 GB. And as luck would have it, amanda would typically get about
30 - 35 GB on the first tape before this file system was ready to be taped.
Then taper would try to write this backup image to tape, and eventually
fail, only to re-start on the next tape (all as expected). But that would
leave a bunch of wasted space on the end of that first tape, with the
result that the Offsite backups would actually require all 3 tapes.
Friday, I added another system to the set of backups -- one that is on
our perimeter net (and thus, subject to firewall restrictions). I was
able to use the "Firewall" entry in the FAQ-o-matic (thank you!), and
then today, for the Offsite backup -- as I half-suspected -- the timing
was such that the 12 GB file system wasn't ready to be taped until amanda
had switched to the second tape already.
So now, because I added another bunch of file systems (including one that
is 3.5 GB used), the Offsite backup only used 2 tapes.
Go figure. :-)
(Tape chunking should address this rather nicely, of course)
Anyway, I thought that some folks might find that vaguely amusing:
>These dumps were to tapes E15, E16.
>The next 3 tapes Amanda expects to used are: E17, E18, E19.
>
>
>STATISTICS:
> Total Full Daily
>
>Estimate Time (hrs:min)0:36
>Run Time (hrs:min)15:25
>Dump Time (hrs:min) 213:22 213:22 0:00
>Output Size (meg) 74162.474162.40.0
>Original Size (meg) 141433.4141433.40.0
>Avg Compressed Size (%)44.3 44.3--
>Filesystems Dumped 150150 0
>Avg Dump Rate (k/s)98.9 98.9--
>
>Tape Time (hrs:min)3:49 3:49 0:00
>Tape Size (meg) 74167.174167.10.0
>Tape Used (%) 211.9 211.90.0
>Filesystems Taped 150 150 0
>Avg Tp Write Rate (k/s) 5517.6 5517.6--
Cheers,
david
--
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
I need help: http://www.whistle.com/employment/employ-engg.html#K030391
>From [EMAIL PROTECTED] Sun Jan 14 17:20:37 2001
>Date: Sun, 14 Jan 2001 17:18:37 -0800 (PST)
>From: System Operator <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Whistle Communications AMANDA MAIL REPORT FOR January 14, 2001
>
Re: taper: FATAL shmctl: Invalid argument
>From: "Shane T. Ferguson" <[EMAIL PROTECTED]> >Date: Wed, 10 Jan 2001 16:13:32 -0400 >My backups appear to run fine (all filesystems were dumped and taped), >however, I always get the following prior to my Statistics: >FAILURE AND STRANGE DUMP SUMMARY: > taper: FATAL shmctl: Invalid argument >I am running Amanda 2.4.2 on all clients and host. What can I do to further >investigate and fix this error? Well, that looks as if it involves the SysV "shared memory", so I suggest that you look at the ipcs command, its output, and its uses -- or whatever comes closest to it (depending on whatever OS you're running). It may well be that you have a bunch of shared memory segments lying about that are no longer in use, for example. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Re: Archive DDS4 tapetype?
>Date: Fri, 05 Jan 2001 17:46:25 -0800 >From: Kevin Hawkins <[EMAIL PROTECTED]> >BTW, does anyone know how to access the loader on a FastStor DLT7000? I >can talk to the tape drive just fine, but the loader is on another SCSI >channel, and I don't have a device which seems to work for it. Any >suggestions? Is there a device list somewhere? Well, I had been using an ADIC FastStor DLT4000, and back in October, replaced it with an ADIC FastStor DLT8000. Since the same code handled both of those autoloaders OK, I presume(!) that it would also cope with the loader (which is the same in all of these cases, from what I understand -- just the drive itself differs) for the DLT7000. In my case, I use the "chio" driver (and command-line program of the same name) written by Jason Thorpe for NetBSD, ported to FreeBSD, and encapsulated in a home-cobbled amanda changer script. I believe that just about anything that runs on your amanda server that can drive a SCSI autoloader ought to work just fine. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Re: config file problems
>Date: Thu, 04 Jan 2001 15:44:53 -0500 >From: "John R. Jackson" <[EMAIL PROTECTED]> >I was interested to hear you were splitting the amanda.conf file into >pieces like this. That had just occurred to me a few days ago, but I >hadn't gotten around to doing it yet. Let me know how it goes. When I split my configuration in two, that is what I did: /usr/local/etc/amanda looks like: eng-backup[1] ls -l /usr/local/etc/amanda total 5 drwxr-xr-x 3 root operator 512 Jan 2 14:07 Eng drwxr-xr-x 3 root operator 512 Dec 17 16:35 Offsite drwxr-xr-x 2 root wheel 512 Jan 3 12:10 Test drwxr-xr-x 3 root operator 512 Jan 2 10:48 common drwxrwxr-x 2 root operator 512 Jan 4 12:18 var where "Eng" and "Offsite" are my 2 (main) configurations, "Test" is another configuration that I'm presently using for trying to re-create the problem I had when the holding disk was rather more full than amanda thought. "common" is where the bulk of the amanda.conf is, and the amanda.conf files in Eng & Offsite include the one from common -- at the end. var is a directory that has the files that amanda needs to write, such as the tapelist; in my case, each of the other subdirectories is not writable by operator (my amanda user). Also, the "disklist" in each of Eng & Offsite is a symlink to the "real" one (in common). It seems to be basically working. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823 I need help: http://www.whistle.com/employment/employ-engg.html#K030391
Re: Why selfcheck does not go to raw disk
>Date: Tue, 2 Jan 2001 11:33:33 -0800 (PST) >From: Wang Chen <[EMAIL PROTECTED]> >I add a new client, did what I did as last time. From >backup server , run amcheck Daily. I got Permission >denied for new adding. Checked the >/tmp/amanda/selfcheck.debug, the line as following: >checking disk c0t0d0s1: device /dev/dsk/c0t0d0s1: >Permission denied . Why the selfcheck goes to check >/dev/dsk/c0t0d0s1 in stead of raw disk >/dev/rdsk/c0t0d0s1? Thank you for help Presumably because the former (/dev/dsk/c0t0d0s1) is what you put in the appropriate disklist file. (It is my understanding & expectation that the "permission denied" message you saw was generated not by a component of amanda (per se), but by the underlying "dump" (or "ufsdump") or (GNU) tar program.) Happy New Year, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: How to reuse a tape?
>Date: Fri, 22 Dec 2000 13:48:31 -0400 (AST) >From: The Hermit Hacker <[EMAIL PROTECTED]> >I tried typing: >%amadmin hub.org reuse Vol_1 >amadmin: tape Vol_1 already reusable. >yet amcheck hub.org tells me that I need a new tape ... Sounds as if the number of tapes amanda knows about that are already written to is less than the claimed tapecycle. >so how does one reuse a tape already written to? *raised eyebrow* To force the issue, "amrmtape" followed by "amlabel". But I'd encourage folks to be pretty sure that the result (including effective destruction of any backup data on the tape in question) is really what is wanted before doing it. And if tapecycle cannot match reality, at least make it an under-estimate, vs. promising amanda more resources than she really has available. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: ip address 63.169.132.238 is not in the ip list for host238
>Date: Fri, 22 Dec 2000 09:10:06 -0800
>From: Mike Windbigler <[EMAIL PROTECTED]>
>I am a bit confused. Is there a host type file for Amanda. I am able
>to do an nslookup on the backup server hosts no problem and the host is
>also in /etc/hosts
But if you do a DNS lookup of the IP address (to find the hostname
returned from a PTR record), it looks as if that hostname doesn't match
what you told amanda to use:
pau-amma[1] host 63.169.132.238
238.132.169.63.IN-ADDR.ARPA domain name pointer host238.o1.com
>Amanda Backup Client Hosts Check
>
>ERROR: slowsrv: could not resolve hostname
>ERROR: mars.o1.com: [ip address 63.169.132.238 is not in the ip list for
>host238
>.o1.com]
(I suspect that there was a spurious line break in the cut'n'paste,
there.)
Anyhow, make the hostname from the PTR record agree with everything else
("mars"), and things should be much happier.
Cheers,
david
--
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: Tape labeling...
>From: Alexandre Oliva <[EMAIL PROTECTED]> >Date: 20 Dec 2000 10:50:07 -0200 >>> amlabel won't let me do that. >> Use the -f option of amlabel. From the amlabel man page... >But note that this will erase the contents of the tape. In fairness, (just about?) any other time the tape is open()ed for write, then close()d, that will also make the rest of the tape unreadable, effectively removing the (former) contents form accessibility. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: permission denied on changer ...
>Date: Wed, 20 Dec 2000 00:37:20 -0400 (AST) >From: The Hermit Hacker <[EMAIL PROTECTED]> >can someone point me at what I'm not seeing here? OS is FreeBSD >5.0-CURRENT ... everything looks normal to me, I think ... >%amcheck hub.org >Amanda Tape Server Host Check >- >Holding disk /usr/local/mp3/amanda: 5348401 KB disk space available, using 5297201 KB >amcheck-server: could not get changer info: /dev/ch0: open: Permission denied >^C >%groups >operator >%ls -lt /dev/ch0 >crw-r- 1 root operator 17, 0 Dec 17 21:57 /dev/ch0 chmod g+w /dev/ch0 Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: Amanda fails to build: amoverview
>From: "ROD" <[EMAIL PROTECTED]> >Date: Tue, 19 Dec 2000 15:36:31 - >I just got around to installing Amanda-2.4.2 stable unfortunately I can't >get it to build on FreeBSD 4.11. The following error is reported: >make: don't know how to make amoverview. Stop >*** Error code 1 >Any help would be appreciated Please see http://www.egroups.com/message/amanda-hackers/2333 (and following thread). (Summary: yes; appears to be a problem with FreeBSD make; see http://www.FreeBSD.org/cgi/query-pr.cgi?pr=23328 for that part. A circumvention is to hack the Makefiles; another is to use gmake.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: [ BUG? ] Running out of disk space...
>Date: Tue, 19 Dec 2000 10:25:10 +0100
>From: Vincenzo Marchese <[EMAIL PROTECTED]>
>> I upgraded to 2.4.2 and I noticed that if dump won't fit on one disk that
>> amdump will go into endless loop trying to do a backup.
>I have the same problem, (sorry this is not a solution :) )
>amdump loops infinitely trying to dump the too-big-fs until you
>kill it by hand.
I've not seen that particular problem (though I use neither tar (for the
backup program) nor Linux, and my aggregate holding disk is about 38
GB).
But I saw something during the backups from this morning that may be
related.
I have 3 holding disks (snapshot while amdump is running):
eng-backup[1]% df -k /hd/tmp{0,1,2}
Filesystem 1K-blocks UsedAvail Capacity Mounted on
/dev/da2s1e 8890016 8178800 16 100%/hd/tmp0
/dev/da3s1e 17704608 2674256 1361398416%/hd/tmp1
/dev/da4s1e 17669856 3354832 1290144021%/hd/tmp2
But I had a couple of failures this morning:
eng-backup# amstatus Eng --failed --summ
Using /var/log/amanda/Eng/amdump from Tue Dec 19 01:53:00 PST 2000
shrimp:/shrimp/usr/local 0 [write_tapeheader: No space left on device] (6:07:45)
shrimp:/usr 0 [write_tapeheader: No space left on device] (6:08:01)
SUMMARY part real estimated
size size
partition : 149
estimated : 149 25019986k
failed : 21472051k ( 5.88%)
wait for dumping: 0 0k ( 0.00%)
dumping to tape : 0 0k ( 0.00%)
dumping : 2 2377536k 4662441k ( 50.99%) ( 9.50%)
dumped : 145 19893760k 18885494k (105.34%) ( 79.51%)
wait for writing: 00k0k ( 0.00%) ( 0.00%)
writing to tape : 1 11437344k 11437820k (100.00%) ( 45.71%)
failed to tape : 00k0k ( 0.00%) ( 0.00%)
taped : 144 8456416k 7447674k (113.54%) ( 33.80%)
98 dumpers idle : not-idle
taper writing, tapeq: 0
network free kps: 1180723
holding space : 24621960k ( 60.46%)
eng-backup#
So the aggregate space required by the 2 failed dumps would have been
around 1.5 GB; I had >25 GB free, but for reasons that aren't (yet)
clear to me, amanda tried to put the (first chunks of the) dump images
on a holding disk that didn't have the space. And there is no retrying
being done.
Looks as if I'm going to need to spend some time going over the logs on
this, to try to find out why amanda's notion of the amount of space on
/hd/tmp0 was so divergent from the OS's. :-( [I'll copy an extract of
the amdump log after my .sig just in case someone else who has more
familiarity with the logs can parse them and point out the weirdness before
I do; the holding disks are named hd0, hd1, & hd2, and refer to /hd/tmp0,
/hd/tmp1, & /hd/tmp2, respectively. The "df" output was done shortly
before I started writing this note, not when the failure occurred, so
there are undoubtedly *some* discrepancies, but the df output should still
be of some relevance. Also, I have the chunksize set to 1900 MB on each
holding disk -- less than 2 GB because although everything else works OK,
the numbers reported by Perl's "-s" operator go screwy when the high-
order bit flips; looks as if Perl's configure ends up using a 32-bit
quantity for the off_t for file size (result from stat()), which should
be an integral 64-bit quantity. (I've gone so far as to cobble up some
C & Perl code to verify the nature of the failure, but haven't yet found
where it's happening, so I circumvented the problem for now.)]
(This is the first time I've seen this behavior with amanda. I won't
object if it's the last)
Cheers,
david (not the David who started the thread)
--
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
driver: send-cmd time 15155.688 to dumper0: CONTINUE
/hd/tmp1/20001219/shrimp._shrimp_home.0 1945600 15712
driver: state time 15155.692 free kps: 1180069 space: 23077320 taper: idle
idle-dumpers: 95 qlen tapeq: 0 runq: 2 roomq: 0 wakeup: 86400 driver-idle:
client-constrained
driver: interface-state time 15155.692 if : free 74149 if DE0: free 81920 if LOCAL:
free 1024000
driver: hdisk-state time 15155.692 hdisk 0: free 10377128 dumpers 3 hdisk 1: free
12700096 dumpers 2 hdisk 2: free 96 dumpers 0
driver: result time 15270.198 from dumper0: RQ-MORE-DISK 01-00289
driver: send-cmd time 15270.198 to dumper0: CONTINUE
/hd/tmp1/20001219/shrimp._shrimp_home.0 1945600 16480
driver: state time 15270.201 free kps: 1180069 space: 23060840 taper: idle
idle-dumpers: 95 qlen tapeq: 0 runq: 2 roomq: 0 wakeup: 86400 driver-idle:
client-constrained
driver: interface-state time 15270.201 if : free 74149 if DE0: free 81920 if LOCAL:
free 1024000
driver: hdisk-state tim
Re: Possible Bug?
>Date: Thu, 14 Dec 2000 18:38:10 -0500 >From: Matt Goward <[EMAIL PROTECTED]> >When attempting to compile amanda 2.4.2 on FreeBSD 3.5 I ran accros trouble >with the Makefiles for server-src and changer-src. In server-src it was giving >me do not know how to make for amoverview. Sounds sounds suspiciously like the symptoms I was seeing (and reported to -hackers). In my case, I was using FreeBSD 4.x; the problem (thanks to JJ) was isolated to being an artifact of an apparent bug in FreeBSD's "make" (PR at http://www.freebsd.org/cgi/query-pr.cgi?pr=23328). At the time I encountered it, I was (also) able to circumvent it via use of gmake, vs. make. >When I went in to look at the make >file the changes needs turned out to be small, but I still figured I should >report it someplace. >Makefiles build with ./configure --with-user=operator --with-group=operator Right; but folks in the amanda project use automake to generate the Makefiles (well, the Makefile.in files), and thus the degree of control over the content of the Makefiles themselves isn't quite what one might like... and more to the point, I am fairly firmly convinced that it's a real bug in (FreeBSD) make. (Your circumvention differs in some respects from mine, but it remains that, rather than a fix.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: What is the meaning of the /usr/local/etc/amanda/changer* files
>Date: Tue, 12 Dec 2000 19:49:11 -0800 >From: Jeff Silverman <[EMAIL PROTECTED]> >Hi. My /usr file system overflowed and so amanda was unable to write to >/usr/local/etc/amanda/changer*. Technically, that's a bug in amcheck >(it ought to detect if those files are writable) but skip that for now. >What I really want to know is what is in those files? I think that >changer-slot is the current slot number. changer-clean might be the >slot with the cleaning tape in it. But what is changer-access? If it >is empty, what does that mean? The files are used by your changer program (or script), if at all. There exist a variety of such programs (scripts); some are supplied with amanda; some are cobbled up at a given installation. But since I can't tell what changer program you use (from the above -- well, I suppose I could look at all of the changer programs supplied with amanda and figure out which ones reference the files you named, and assume that you're using an amanda-supplied one...), I can't tell you the answer to your question. I suspect that you're correct about changer-slot, though someone could have been Very Perverse in writing a changer script And as for amcheck, it can tell the name of the changer program (if any) you specify that you want to use, but it cannot tell what (if any) auxiliary files that program might use or how it intends to use them. (Maybe the changer script API should be slightly modified to accept a "check" parameter; if that is specified, the script could do its own reality-check routine, whine as appropriate, and return !0 if something appears wrong. And if the changer can't cope with "check", it should just return some defined value -- either 0 for backwards-compatibility or (say) 1 for "I haven't a clue what you're talking about". Then amcheck could invoke the changer with the "check" parameter) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: dump level prematurely returns to 0
>Date: Fri, 8 Dec 2000 10:21:36 -0800 >From: peanut butter <[EMAIL PROTECTED]> >H. Ok. But what factors would Amanda see as a need to >"promote" a disk? You might want to think of it as "opportunity", vs. "need". Remember, "Good Thing". :-) >If a level 0 is done and then subsequent level >1's and maybe a level 2 ensue, why would Amanda suddenly feel the need >to think, "h, I'll do another level 0 on that disk"? Because the tradeoff seems worthwhile. If she could get away with it, the ideal would be a full backup each time amdump is run. >Why not go to level 3 if level 2 isn't doin' it for her anymore? Depends on the dumpcycle & runspercycle, as well as how much data is being backed up -- htat is, the amount of data needed to record a backup of a given level. For example, if most of the files for a given filesystem just got modified, she might as well (in all probability) jst do a level 0, vs. an "incremental" where nearly everything is copied anyway. >You are right, it's not a bad thing but it does seem unnecessary and, if >so, uses unnecessary tape. I'd be a little more concerned about "unnecessary time" than "unnecessary tape" -- but that's just me. :-) The tape usage is at the granularity of an integral number of tapes -- if amanda writes on a tape at all during an amdump (or amflush) run, she's written on it, period. Might as well take advantage of the rest of the tape, too. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: amflush wait for amdump to finish?
>Date: Mon, 04 Dec 2000 16:50:49 -0700 >From: Eric Wadsworth <[EMAIL PROTECTED]> >Should I wait until amdump finishes before I do an amflush? The flush would be >of the stuff that amdump is currently dumping to. Assuming that you want the results of the amdump to be written to tape (via the amflush), yes. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: amlabel
>Date: Sun, 3 Dec 2000 22:47:49 + >From: Clement Kumah <[EMAIL PROTECTED]> >I wonder if anyone can tell me what the following error is after using amlabel on a >FreeBSD 4.2 system. > amlabel -f DailySet1 DailySet101 slot 1 >labeling tape in slot 1 (/dev/nrsa0): >rewinding, reading label DailySet101, tape is active >rewinding, writing label DailySet101, checking label, done. >amlabel in free(): warning: junk pointer, too high to make sense. >BTW, I'm using amanda-2.4.2-19991216-beta1 This is almost assuredly not an amanda problem. We (in the FreeBSD community) saw this back in FreeBSD 3.2 (I think -- memory's hazy on those details, and I haven't time to check the archives right now), and the problem appeared to be correlated with inetd at the time. (For example, we would see it pop up on our local CVS server.) FWIW, I also see it occasionally on my amanda server (running FreeBSD 4.1.1-STBALE as of 29 September, at the moment). I suggest attacking this from the FreeBSD side of things Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: linux filesize limit and amanda?
>Date: Mon, 20 Nov 2000 17:52:54 -0500 >From: Michael Lea <[EMAIL PROTECTED]> >Sorry if this is covered elsewhere, but I couldn't find anything about it. >My understanding of the way that amanda works is that it streams the >dump file to the holding disk on the tapehost, and then that gets written to >the tape. In my case, an x86 linux box is the tapehost, and it backs up >some solaris boxes. So my question is, what happens when it's backing >up a filesystem that is larger than the 2gb filesize limit? I have run >into that problem trying to restore a large solaris filesystem dump, how >does it backup large filesystems like that? That's what the "chunksize" specification (for a given holding disk) is for in the amanda.conf -- to break up the backup image into pieces that are manageable on the OS & file system in question. (The chunks get concatenated when the image is written to tape, so there is -- for now, anyway -- no way to tell how many chunks the image was originally written in. This is a Good Thing, because that way, the "chunking" cannot interfere with the recovery process.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: Can DLT7000 inter-operate with DLT4000?
>From: Alexandre Oliva <[EMAIL PROTECTED]> >Date: 18 Nov 2000 05:51:47 -0200 >(i) in case the DLT4000 robot fails, the DLT7000 tape drive will be >able to read backups done with it, and >(ii) after the DLT4000 robot is fixed, it will be able to read tapes >written by the DLT7000 drive. The autoloader with which I started using amanda was a 7-slot ADIC device with a DLT 4000 drive (August, 1998). I had told my manager that sometime around spring of this year, we should plan on going to a DLT 8000 drive. We did this (though it took longer than expected); it arrived in mid-October, just before I went on a 2-week vacation (for the first time in years). Since we have a dedicated amanda server, it isn't being used when the backups aren't running (and I'm not tweaking it); I was able to swap the devices and do some preliminary testing. Basically, the drive worked just fine without making any changes to the amanda configuration -- though we weren't making optimal use of its capabilities. Given that I was going to be out of the office for a while, I chose to leave well enough alone until my return. After I got back, I found that amanda had run trouble-free; given that, I started making changes to take advantage of the DLT 8000 -- briefly, it holds twice as much (40 GB vs. 20 GB native) and writes as much as four times (6 MB/s vs. 1.5 MB/s) the DLT 4000 drive. (Tape writing speed is nowhere near the bottleneck now.) >From this, we may observe that the DLT 8000 drive had no trouble reading the tapes that had been written with the DLT 4000 drive -- I did not need to re-label the tapes (via amlabel), for example. And I believe I did a restore or two, using the DLT 8000 drive, from backups that had been written with the DLT 4000 drive. Although I have not tested it, I would not expect that the DLT 4000 could read tapes written by the DLT 8000, though -- unless there's some way to force the DLT 8000 to *write* in DLT 4000 mode, which I doubt. I would expect similar considerations to apply to a DLT 7000. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: ejecting amanda tape - after dump finishes
>Date: Fri, 17 Nov 2000 15:48:40 + (GMT) >From: Denise Ives <[EMAIL PROTECTED]> >Can Amanda be configured to automatically eject the tape from the tape >drive when a dump to tape is finished? >Or should I write a perl or shell script to automate the both the dump and >eject tape process? I believe that the latter approach is the one generally used. In my case, I have the script rune "amcheck" at the end (to have some semblance of a reality check that all is in order for the next backup run). Since I'm using an autoloader, running amcheck ejects the tape that was most-recently written (and tries to find the next one to write). Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: Using Amanda to backup a NFS mounted FS.
>Date: Thu, 16 Nov 2000 18:16:07 -0600 >From: Miles Lott <[EMAIL PROTECTED]> >Just out of curiosity, why would you opt >to do it this way. Doesn't amanda provide >a way to do this client-server? A reason is that the NetApp Filer is not a general-purpose UNIX machine; porting the amanda client code to it may or may not be trivial, but it would require the cooperation (if not assistance) of NetApp to do it right. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: Using Amanda to backup a NFS mounted FS.
>Date: Thu, 16 Nov 2000 11:31:42 -0800 (PST) >From: Nate Eldredge <[EMAIL PROTECTED]> >> Can Amanda be used to backup an NFS mounted filesystem ? I have a >> Network Appliance >> box and have mounted the exported filesystem to a mount point on the >> Amanda server >> The Sun is running Solaris 7. >Yes, it's working fine here. You just have to use tar. Obviously you >can't use dump, because you don't have access to the raw disk (and even if >you did, Solaris wouldn't have any idea what to do with it). Indeed. :-} >Another hint: If you have snapshots enabled, you will probably want to >exclude them (amanda documentation explains how to exclude directories). Alternatively, you might want to create a snapshot for the purpose and back up (only) that. (A NetApp "snapshot" is read-only for the lifetime of the snapshot, so things won't be changing out from under it.) Then you can delete the snapsht when you're done, or queue it for deletion, depending on local policies. Also, to address the concern that someone else had, it is possible to provide a NetApp Filer with an additional NIC; if you do the backups via that (dedicated) NIC, it's likely to significantly reduce the impact of the backups on your "regular" net(s), quite possibly to the point that no one will notice when the backups are being done. :-} Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
RE: hostname lookup failed
>Date: Thu, 16 Nov 2000 13:24:52 -0600 (CST) >From: Joi Ellis <[EMAIL PROTECTED]> >>I'm pretty sure that all (UNIX) versions of nslookup uses gethostbyname(); >>... >I'm not sure of this at all. On our internal machines, various breeds >of linux and solaris, nslookup doesn't return an answer if there is no >DNS entry for the name in question, EVEN IF that host is named in the >/etc/hosts file. Yup -- I was incorrect: nslookup *only* does DNS queries; it does not pay attention to any other mechanisms for hostname resolution. >Some versions of nslookup will accept an IP address, ie the Linux flavor >will, but default Solaris flavors won't. Right. Sorry for any confusion, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
RE: hostname lookup failed
>From: Thorsten Flick <[EMAIL PROTECTED]> >Date: Thu, 16 Nov 2000 16:37:49 +0100 >DNS is running well. and i administer it for myself. Good -- reducing the effects of "middlemen" helps get work done. :-} >> [stuff about gethostbyname() & gethostbyaddr()...] >Ok, i will test this. But, did nslookup not use them ? I'm pretty sure that all (UNIX) versions of nslookup uses gethostbyname(); I'm less confident about their use of gethostbyaddr(). (I'm pretty sure that there have been some versions of nslookup that would try to do a gethostbyname() using an IP address as an argument, if you gave it an IP address. But the machine I have where that was likely the case stopped working a few months ago, and I don't have the time to get a Sun 3/60 running again... and I'm digressing. For those versions of nslookup, it was generally necessary to feed it something of the form ddd.ccc.bbb.aaa.in-addr.arpa (assuming an IP address "aaa.bbb.ccc.ddd").) For the past few years, I've found the "host" command more useful for diagnosing DNS issues. There's also DiG, but I confess I haven't got around to learning how to use it -- host does enough for nearly all of my needs (and it's shorter to type than "nslookup" :-) -- though not as short as "dig"). In any case, "host" will perform a gethostbyaddr() if you give it a normal IP address: pau-amma[1]: host www.sun.com www.sun.com has address 192.18.97.241 pau-amma[2]: host 192.18.97.241 241.97.18.192.IN-ADDR.ARPA domain name pointer www.sun.com (The "nslookup", "host", and "dig" commands I'm using are all part of the BIND 8.x distribution from ftp.isc.org.) >Thnx for your answer ... Glad to help, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: hostname lookup failed
>From: Thorsten Flick <[EMAIL PROTECTED]> >Date: Thu, 16 Nov 2000 15:20:00 +0100 >i have a new Problem if i want to include another host in my backup. >amcheck says the following : >-- >Amanda Backup Client Hosts Check > >ERROR: intranet: [addr 192.168.1.42: hostname lookup failed] >Client check: 3 hosts checked in 0.318 seconds, 1 problem found. >(brought to you by Amanda 2.4.1p1) >- >Server and Client are running the same Server-Version. OK; so fix the DNS (or whatever alternative hostname resolution mechanism you use), or get the folks who administer it (if you don't) to do so. Basically, in addition to being able to determine an IP address for a given hostname (gethostbyname()), it should also be possible to determine a hostname for a given IP address (gethostbyaddr()). And the results ought to be sufficiently consistent that given some (valid) hostname, one should be able to perform a gethostbyname() on that, then go through the list of IP addresses returned, performing a gethostbyaddr() on each, and at least one of the returned hostnames (from the gethostbyaddr()) ought to be a case-insensitive match for the original hostname. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: Wait - are you saying that I don't have to re-label each of my tapes?
>Date: Tue, 14 Nov 2000 23:14:53 + (GMT) >From: Denise Ives <[EMAIL PROTECTED]> >Does this have anything to do with the tapecycle parameter in the >amanda.conf file and which tape to use next? ># Backupcentral.com/Amanda tape labeling ># Each tape assigned to a configuration needs a unique label. Tapes must >be pre-labeled with amlabel so AMANDA can verify the tape is one it >should use. Run amlabel as the AMANDA user, not root. For instance: ># su amanda -c "amlabel daily daily123" It would appear to (though I confess I don't recognize the source of the above; it doesn't appear to be part of the sample amanda.conf, for example). >>Why do you want to relabel tapes each time? Amanda will tell you (via >>amadmin or amrecover) which tape has which dump image on it. >***Example: I have tape daily555 in the tape drive right now. >When I run amadmin tape I get these results: >*** >amanda@sundev1 [daily] % amadmin daily tape >The next Amanda run should go onto a new tape. That is a function of factors such as tapecycle (from amanda.conf). >*Example: When I run amcheck - Amanda tells me it >will not overwrite tape daily555 Indeed; this is a feature. >>I don't think most people relabel tapes every time, and certainly not >>with meaningful encoding of such things as the date they were used. Quite; amanda records such information already. >>The typical method is to just create a set of tapes and let Amanda cycle >>around through them, i.e. daily00, daily01, daily02, daily03. Yup. >amanda@sundev1 [daily] % amcheck daily >Amanda Tape Server Host Check >- >/dump/amanda: 10171924 KB disk space available, using 9659924 KB. >ERROR: cannot overwrite active tape daily555. > (expecting a new tape) >NOTE: skipping tape-writable test. >This is why I have been re-labeling the tapes each time. After I force >the re-label of a tape amflush runs without fail. I also re-label each >tape when I need to run a full dump. I never thought that made any sense >- but I guess Amanda doesn't want to overwrite good Valid images. Right; that's why it is a "feature". >amlabel -f daily newlabel >Here is my tape list file. >daily119 is a full dump >daily 112 has a weeks worth of incrementals >daily118 is a full dump >daily555 has a weeks worth of incrementals >Tape labels daily01 and daily02 - are now tape labels daily119 and >daily112 >I just didn't remove them from the tape list - amrmtape I suggest minimizing the extent to which amanda's configuration information mis-matches reality. Having such mis-matches tends toward increasing confusion. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
re: sugestion for tape labeling Yea or Nea?
>Date: Tue, 14 Nov 2000 21:56:18 + (GMT) >From: Denise Ives <[EMAIL PROTECTED]> >There is an admin here who suggested I >modify the labelstr. Will this work? >- you should modify >labelstr to "$[0-9][0-9][0-9]" Changing the labelstr may be useful. But since it's a (Perl) regex, I'd be rather surprised if a string with non-terminating "$" characters would be useful for anything: that character is used to provide an "anchor" for the right-hand side of the string. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: tape labeling scheme
>Date: Tue, 14 Nov 2000 18:03:01 + (GMT) >From: Denise Ives <[EMAIL PROTECTED]> >How can I identify amanda tapes by level of dump? I can label a tape >that had a full dump on Nov1 as daily111 but I can't label a tape >that had a full dump on Nov 24th as daily1124. I'm sorry, but I think the question indicates a misunderstanding. You may well have things set up so that the idea of a (single) "level of dump" on the tape corresponds to something that an observer could reference... but I submit that such a configuration would be rather anomalous for amanda. (Granted, I set things up so that there are respects in which my amanda configuration is rather anomalous, too) But usually, amanda will use a mixture of levels during a given dump run, and the resulting backup images will get written to some set of tapes. As a result, each tape is likely to have a mixture of full and incremental (often, of differing levels) backup images on it. That's (generally) OK; amanda keeps track of what is where, so you can restore any object that is backed up to its state as of any date it was backed up. Where things get potentailly messy with this scheme is with "disaster recovery preparedness" -- you would need to keep an entire dumpcycle's worth of media in the "safe location" of your choice. (And if that is off-site, you no longer have access to these media while you are on-site.) Other folks have written about what they do, in ways that are likely better than I could, so I'll stop here. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: How many dumpers active?
>Date: Thu, 09 Nov 2000 18:42:16 -0500
>From: "John R. Jackson" <[EMAIL PROTECTED]>
>>How do I know how many dumpers are active? ...
>Amanda will start the number you tell it to.
Up to MAX_DUMPERS (which in my copy of server-src/driverio.c is 63).
>The real question is,
>how well are they being used. The easiest way to tell is with amstatus.
>In particular, running it against a completed amdump. file.
amplot is handy for this, as well (and for checking on various resource
constraints in general).
>For instance, I have this as part of my "run-amanda" script right
>after amdump (the syntax may be different at 2.4.1p1 -- I forget):
> amstatus ${config} --summary --file amdump.1
>Since the most recent amdump. file is always amdump.1, this gives
>me a summary of what happened during this run.
>Part of the output looks like this (although I just noticed it's broken
>with 2.4.2 -- sigh :-):
(What's "broken" about it...?)
Cheers,
david
--
David Wolfskill [EMAIL PROTECTED] UNIX System Administrator
Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: Using an old tape
>Date: Thu, 09 Nov 2000 15:47:48 -0300 >From: Gonzalo Arana <[EMAIL PROTECTED]> >If I configure a 4 tape cicle (full backup each, none incremental), and the last >dump is on tape 3. How may I retrieve de dump on tape 2? >Sory if my question is quite basic, but I haven't found anything on the >amrecover manpage. >Waiting for answers, Use the "setdate" command within amrecover (to specify the date as of which you want the restore done). If you are not sure of the date, use the "history" command to see the correspondence between dates and tape labels. You will probably be well-advised to peform the "mt fsf" command (to forward space to the proper file number) before telling amrecover to use the tape in question. Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: tape control and amanda
>Date: Mon, 06 Nov 2000 10:45:11 + >From: Clem Kumah <[EMAIL PROTECTED]> >I need some help. I have installed amanda-2.4.2-19991216-beta1 on >Freebsd 4.1 >I have a Breecehill tape robot with 15 cartridges in it. I have noticed >the changer device is set to /dev/ch0. The actual device is listed as >/dev/pass1. How can I change this? By specifying the "ch" (SCSI media changers) in your kernel configuration -- see /usr/src/sys/i386/conf/LINT for a sample such line. >Secondly, is it possible to use mt or chio to manual move the robot >changer, any examples would be appreciated Yes; once the "ch" device is defined to the kernel, Jason Thorpe's "chio" driver will be available, as will the program of the same name. There's a changer script called "chg-chio" that Nick Hibma wrote; I suspect it will suit your purposes well. (I happen to (still) use one that I cobbled up around the rime Nick was writing chg-chio. I can send it to you if you like, but I strongly suggest that you use chg-chio if at all feasible.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
