RE: Resolved - Multi-tape question

2002-02-27 Thread Tuthill, Ed

What I did here is not the second drive with the changer at all -- I change
that tape by hand twice a week, and use it to generate an archival level-0
backup  (stored in the tape safe) for long-term storage.  I can use the
tapes in the changer (on drive 1) to restore any file system to any day in
the previous 20 days (since I have a 20-slot changer) and then can restore
to one-week granularity for any week in our tape safe (which goes back two
years).

I know it's not using both tape drives WITH the changer exactly, but it
works well for our needs.

-Ed


> -Original Message-
> From: Mark Lin [mailto:[EMAIL PROTECTED]]
> Sent: 27 February, 2002 08:02
> To: Eric Trager; [EMAIL PROTECTED]
> Subject: Re: Resolved - Multi-tape question
> 
> 
> Perhaps add another configuration, use the second drive as 
> your tapedev
> parameter and change the first and last slot number in your 
> changer conf
> file.  So first conf will have slots 1-15 and second conf will control
> 16-30.  Have them backup different filesystem.  Althought I 
> dont know if it
> would work better since we can't have two copies of Amanda 
> running the same
> changer at the same time, so backup speed wise, it's probably 
> the same.  I
> am not sure if multiple copies of amanda can run the same 
> time, someone
> please correct me if I'm wrong.
> 
> - Original Message -
> From: "Eric Trager" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, February 27, 2002 9:53 AM
> Subject: Resolved - Multi-tape question
> 
> 
> >
> > Thank you to those that wrote back yesterday, especially 
> Don. I used the
> > non-compressed device (in this case, /dev/rmt/1n), and 
> amanda did indeed
> > write filesystems until it hit EOT and rewrote that 
> specific interrupted
> > filesystem to the next tape.
> >
> > Does anyone here have a changer working with more than one 
> drive? The
> > 30-slot StorEdge changer I'm working with has two drives 
> installed, and
> > I'm wondering how I can best utilize both of them.
> >
> > - Eric
> >
> >
> >
> 



RE: run out of space

2002-02-13 Thread Tuthill, Ed

The amcheck does not check tape space, only that there is a labelled tape.
It should know the amount of tape space available based on the tapetype
configured.

When the dump actually happens, amanda will first reduce full backups to
incremental backups if there is too much data for the tape size, and then
exclude file systems that are too big to fit on the tape if it can't do
incrementals (such as if you have "full-only" file systems marked).

It will back up as much as it can, basically.

> -Original Message-
> From: Monserrat Seisdedos Nuñez [mailto:[EMAIL PROTECTED]]
> Sent: 12 February, 2002 00:58
> To: Amanda-Users (E-mail)
> Subject: run out of space
> 
> 
> 
> 
> Hello:
> i know amanda  does a check before dump data, but does it 
> include a space
> tape check??
> i wonder what happen if the fs are grater than the tape 
> capacity, is the
> entire backup thrown away or it back up only the fs that fit the tape?
> Thanks
> 



Oracle Backup Strategies

2000-12-06 Thread Tuthill, Ed

To those who have been waiting on my Oracle backup perl script,
I just wanted to let you know I haven't forgotten about you.
My supervisor insisted on bringing our legal department into
the loop since the script was created on Sprint's dime.  I'm
pushing to get this declared freely distributable so that I
can share it here.  

FWIW, it's been running for about a week now, and has been
doing fairly well, although I'm still tweaking.

-Ed

Edward Tuthill
NTAC Engineer, Sprint PCS NTAC-West
W: 949.225.2920
M: 310.663.9726



RE: Backing up Oracle database

2000-11-21 Thread Tuthill, Ed

I'm putting the finishing touches this week on a perl script
that handles Oracle database hot backups (to keep the database
up and running 24/7).  It's very much like the tcl script John
Jackson wrote, but uses the Expect perl module to interact with
the database.

The script essentially backs up all of the tablespaces, control
files, and config files to a spare partition set up specifically
for this purpose.  This partition is then set to be backed up
with Amanda, along with all the regular partitions on the
system  (e.g., /usr, /var, etc.).

So if you'd like to look at a perl version of this, let me know
and I can ship a copy your way.


> -Original Message-
> From: Fredrik Persson P (QRA) 
> [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 20, 2000 8:46 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Backing up Oracle database
> 
> 
> 
>   [Fredrik Persson P (QRA)]  Please read the entire mail! 
> In the end, I'm coming to a conclusion that
>   probably obsoletes a lot of the previous junk that I 
> wrote. I've been writing this email all day and 
>   I've become wiser along the day too...
> 
> > >I've been assigned the task to back up an Oracle database 
> w/ amanda. I'm
> > >also told (by the db administrator) that a have to read 
> the files under /u02
> > >(a directory in the root of the file hierarchy) in a 
> certain order. 
> > 
> > Ummm, that's very odd.  I've talked with my Oracle admin 
> and we're not
> > sure what it is you're trying to do here.  Could you elaborate?
> > 
>   [Fredrik Persson P (QRA)]  Absolutely! Our main concern 
> seems to be that the
>   database must operate 24/7. The scheme that we thought 
> up was to run the "begin
>   backup" command on all tablespaces before amanda starts 
> her work. When she's
>   finished, the "end backup" command is run on all 
> tablespaces. When all the tablespaces
>   are brought "back into action", the command ALTER 
> SYSTEM SWITCH LOGFILE is issued,
>   to create a new ARCHIVELOG file, even thought the old 
> one might not be "full". 
> 
>   To restore the contents of the db, we first bring the 
> tablespaces back, and then apply
>   the archivelog file to them. Now, there seems to be a 
> file called the "control file". If this
>   file is backed up before the tablespaces, and the 
> tablespaces are altered during backup,
>   we cannot restore the system. The control file is out 
> of date and we get an error message
>   similar to "control file older than tablespace". Can't 
> recall the exact words, but that's what 
>   it means.
> 
>   So, what I want to do is to backup the tablespaces 
> first, and the control file after that. That's
>   why I need to tell amanda to do things in a certain order.
> 
> > Also, the way we back up our Oracle system is to dump it to 
> a scratch disk
> > area and then let Amanda back that up.  And yes, we've done 
> restores :-).
> > And they even worked :-).
> > 
>   [Fredrik Persson P (QRA)]  Are you running 24/7? If so, 
> how do you deal with the issue
>   of changes in the db during file transfer? Do you use 
> raw partitions or does Oracle run on top
>   of a file system?
> 
> > The scripts we use are at:
> > 
> >   ftp://gandalf.cc.purdue.edu/dbbackup.*
> > 
>   [Fredrik Persson P (QRA)]  That link didn't work. Did 
> you mean ftp://gandalf.cc.purdue.edu/pub/amanda/dbbackup.*
> 
> > >Is there a way to tell Amanda this?
> > 
> > If this really ends up being the way you need to do this, I 
> have some
> > hacks that I think would work.  But let's make sure you're 
> headed down
> > the right path first.
> > 
>   [Fredrik Persson P (QRA)]  After spending the day 
> pondering this issue, I think we've come to the conclusion that 
>   we'll copy the db files to a temp storage, and then 
> backup them from there as if they were regular files.
> 
>   This is your approach too. I'd say it's a good one. 
> Minimizes db backup time and gives us control 
>   over the order when storing db files. 
> 
>   I've browsed your scripts. Are those GPL'ed or 
> something similar? Right now, we're using our own scripts
>   that can be said to be stripped versions of yours. 
> However, I might be interested in your stuff later.
> 
>   Thanks for your help! Using a temp storage was pretty smart.
> 
>   /Fredrik Persson
> 



RE: Er... amrecover says "Ip address 10.0.0.100 is not in the ip listfor myserver.mydomain.com"

2000-10-27 Thread Tuthill, Ed

> I thought that nslookup is going to find out the answer in 
> *exactly* the
> same way as the resolver library on my system does - that's what I
> learned from O'Reilly's "DNS and BIND".  Do you mean this is 
> not so and
> I don't have to trust it, as the book taught me? If so, what 
> do we still
> have nslookup for?

The definitive program to do a lookup the same way the resolver library does
is 'getent'.

Use 'getent hosts foo' to find out what the resolver thinks the host 'foo'
is.

-Ed