Configuration help?
Hello again everyone! Now that I have sorted out my tapetype issue I kindly ask for some help on configuring Amanda. What I would like to do is: - full backups every weekday (mon-fri) - use 5 tapes (possibly 6) - backup the following filesystems host: louie filesys: /export/home/htdocs host: louie filesys: /export/home/htdocs-utv host: bagheera (win2k server) \\bagheera\misc The questions is, how to I write the disklist and amanda.conf correctly (I have succeded in doing a small test to just backup a unix partition). Should I have: dumpcycle 1 week runspercycle 5 tapecycle 5 and force all backups to be full backups? Or maybe I could have dumpcycle 1 day runspercycle 1 tapecycle 5 and use cron to schedule it on weekdays only? I am a bit unsure about how to set the parameters so any pointers would be most appreciated. Thanks in advance! /Conny
Re: Configuration help?
On Wed, 14 Aug 2002 at 4:27pm, Conny Gyllendahl wrote > What I would like to do is: > > - full backups every weekday (mon-fri) > - use 5 tapes (possibly 6) > - backup the following filesystems > > host: louie filesys: /export/home/htdocs > host: louie filesys: /export/home/htdocs-utv > host: bagheera (win2k server) \\bagheera\misc You need a *nix client with the samba client bits installed in order to get the 'doze box. The disklist entry would look like: $UNIX_HOST //bagheera/misc $DUMPTYPE_USING_TAR > Or maybe I could have > dumpcycle 1 day > runspercycle 1 > tapecycle 5 > and use cron to schedule it on weekdays only? Close. Set dumpcycle to 0 -- that will force all level 0s. And, yes, use cron to run amdump on weekdays only. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Configuration help?
On Wed, 14 Aug 2002, Joshua Baker-LePain wrote: *snip* 1000 x thanks for the help! I have Amanda up and running and backing up our three servers just the way we wanted it now. Now for my last question for this time: what are the pros and cons, if any, for using tar or (ufs)dump? Are there any reasons or situtations for choosing one over the other? /Conny
Re: Configuration help?
On Fri, 16 Aug 2002 at 10:07am, Conny Gyllendahl wrote > 1000 x thanks for the help! I have Amanda up and running and backing up > our three servers just the way we wanted it now. Glad to hear it. > Now for my last question for this time: what are the pros and cons, if > any, for using tar or (ufs)dump? Are there any reasons or situtations > for choosing one over the other? Tread lightly -- thar be dragons here. :) They both have their pros and cons, and it can be a matter of deep seated religous belief for people. FS specific dump programs can back up things that tar doesn't know about (e.g. ACLs), and can sometimes be faster. But they're limited to partitions only, and require that the recovery machine have them installed. Tar can do subdirectories and doesn't care about OS/FS (and thus you can recover on just about any machine). It's all a matter of choice. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Configuration help?
On Fri, 16 Aug 2002, Joshua Baker-LePain wrote: > Tread lightly -- thar be dragons here. :) They both have their pros and > cons, and it can be a matter of deep seated religous belief for people. > FS specific dump programs can back up things that tar doesn't know about > (e.g. ACLs), and can sometimes be faster. But they're limited to > partitions only, and require that the recovery machine have them > installed. Tar can do subdirectories and doesn't care about OS/FS (and > thus you can recover on just about any machine). > > It's all a matter of choice. Basically I agree with Joshua, with one addition. For Linux systems stick with tar. dump on Linux is, well, not know for being robust. -Mitch
Re: Configuration help?
On Friday 16 August 2002 03:07, Conny Gyllendahl wrote: >On Wed, 14 Aug 2002, Joshua Baker-LePain wrote: > >*snip* > >1000 x thanks for the help! I have Amanda up and running and > backing up our three servers just the way we wanted it now. > >Now for my last question for this time: what are the pros and > cons, if any, for using tar or (ufs)dump? Are there any reasons > or situtations for choosing one over the other? > >/Conny Thats an almost religious battle that seems to not have a definitive answer and I'd rather not throw any more starter on the fire. Me, I use tar, if for no other reason than it can accept an exclude list of things not to backup, like the holding directory if its not on a seperate partition thats not in the disklist. Someone else will have an equally valid reason to use dump, like its faster or ??? Read the comments said here, read the manpages and decide which collection plate to put your tithe in. :-) -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.11% setiathome rank, not too shabby for a WV hillbilly
Re: Configuration help?
On Fri, Aug 16, 2002 at 10:07:54AM +0300, Conny Gyllendahl wrote: > On Wed, 14 Aug 2002, Joshua Baker-LePain wrote: > > Now for my last question for this time: what are the pros and cons, if > any, for using tar or (ufs)dump? Are there any reasons or situtations > for choosing one over the other? One more point for tar (not better, just a capability) ... As Joshua pointed out tar can backup directory trees. This is sometimes necessary to split a huge partition into pieces that fit on a single tape. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Configuration help?
On Fri, Aug 16, 2002 at 10:07:54AM +0300, Conny Gyllendahl wrote: > Now for my last question for this time: what are the pros and cons, if > any, for using tar or (ufs)dump? Are there any reasons or situtations > for choosing one over the other? You say "ufs(dump)", so I'm assuming recent Solaris. The calculation is different for Linux. ufsdump plus: - Gets all file system/file attributes, period, no ifs ands or buts, even ones you don't know are there. :-) - Does not touch atime on files. - Does not require running as root. - In my experience, on file systems with large numbers of small files, estimates and incrementals are much faster than GNU tar. ufsdump minus: - No exclude list. - No splitting the file system. - Data is not portable to other OS's. tar plus: - Flexibility. Excludes, splitting. - 100% portable, ubiquitous. (But see also tar minus) tar minus: - Touches atime. - In my experience, on file systems with large numbers of small files, estimates and incrementals can take a long time. - "Portable, but": GNU tar output with very long paths/names is only guaranteed to be readable by another GNU tar of "similar" version. Reading with non-GNU tar (or older GNU tar) may generate errors, or garbled paths/names. Depending on the versions involved, things get interesting at name lengths of 100 or 256, and path lengths of 256 or 1024. This is a very minor minus, you just need to be aware. - Has to run as root (no, I don't lose any sleep worrying about runtar exploits! :-) Speed folklore: In my experience, on full backups, on modern Solaris kit, GNU tar is a bit faster than ufsdump, *not* slower. Disks have gotten a lot faster (helps the more-random seeks that tar has to do), ufs and the processors have gotten faster (so ufs isn't "in the way" any more), and ufsdumps's initial mapping (wonderful for 'ufsrestore -i') is just time down the drain from amanda's POV. There, no religion here, I think. Look at the plus/minus lists and make up your own mind. As the Perl folk say, TMTOWTDI. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: Configuration help?
On Fri, Aug 16, 2002 at 10:08:49AM -0700, Jay Lessert wrote:
>
> There, no religion here, I think. Look at the plus/minus lists and
> make up your own mind. As the Perl folk say, TMTOWTDI.
>
For those like me who did not know Jay's acronym:
$ dict TMTOWTDI
*** Source: Jargon File (4.3.0, 30 APR 2001) ***
TMTOWTDI /tim-toh'-dee/There's More Than One Way To Do It. This
abbreviation of the official motto of {Perl} is frequently used on
newsgroups and mailing lists related to that language.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Configuration help?
On Fri, 16 Aug 2002, Joshua Baker-LePain wrote: > Tread lightly -- thar be dragons here. :) They both have their pros and > cons, and it can be a matter of deep seated religous belief for people. > FS specific dump programs can back up things that tar doesn't know about > (e.g. ACLs), and can sometimes be faster. But they're limited to > partitions only, and require that the recovery machine have them > installed. Tar can do subdirectories and doesn't care about OS/FS (and > thus you can recover on just about any machine). Hmm.. odd, I have been using a dumptype using ufsdump for just subdirectories and it appears to be working. Or maybe amanda is smarter than me, notices it and switches them to using tar instead. :) -- Conny Gyllendahl His mind is like a steel trap: full of mice. -- Foghorn Leghorn
Re: Configuration help?
On Fri, 16 Aug 2002, Jay Lessert wrote: > You say "ufs(dump)", so I'm assuming recent Solaris. The calculation > is different for Linux. Correctamundo! Solaris 2.8 to be precise. *snip great list of pros and cons* Thanks for the input! -- Conny Gyllendahl It is not enough to have great qualities, we should also have the management of them. -- La Rochefoucauld
Re: Configuration help?
On Tue, Aug 20, 2002 at 10:27:16AM +0300, Conny Gyllendahl wrote: > On Fri, 16 Aug 2002, Joshua Baker-LePain wrote: > > > Tread lightly -- thar be dragons here. :) They both have their pros and > > cons, and it can be a matter of deep seated religous belief for people. > > FS specific dump programs can back up things that tar doesn't know about > > (e.g. ACLs), and can sometimes be faster. But they're limited to > > partitions only, and require that the recovery machine have them > > installed. Tar can do subdirectories and doesn't care about OS/FS (and > > thus you can recover on just about any machine). > > Hmm.. odd, I have been using a dumptype using ufsdump for just > subdirectories and it appears to be working. Or maybe amanda is smarter > than me, notices it and switches them to using tar instead. :) >From Solaris 2.8 man page of ufsdump: files_to_dump Specifies the files to dump. Usually it identifies a whole file system by its raw device name (for example, /dev/rdsk/c0t3d0s6). Incremental dumps (levels 1 to 9) of files changed after a certain date only apply to a whole file system. Alternatively, files_to_dump can identify individual files or directories. ... This dump is equivalent to a level 0 dump of the indicated portions of the filesystem ... It looks like by naming a directory you do a level 0 each time unless (perhaps?) that directory is the mount point. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Configuration help?
On Tue, 20 Aug 2002, Jon LaBadie wrote: > Alternatively, files_to_dump can identify individual > files or directories. ... This dump is equivalent > to a level 0 dump of the indicated portions of the > filesystem ... > > It looks like by naming a directory you do a level 0 each time unless > (perhaps?) that directory is the mount point. Looks like it, though I cannot speak for its behaviour if I specified a mount-point. Either way, through sheer luck, it works just like I wanted it to (ie: doing level 0 dumps all the time). /Conny
Archival tape backup configuration help
Ok, I have my daily tape backup set configured and working perfectly. Now I
want to setup an archival (available for offsite storage) backup strategy.
Here is how I want it to work:
Week 1: Full backup to tapes 1 and 2
Week 3: Take tapes 1 and 2 offsite
Week 5: Full backup to tapes 3 and 4
Week 7: Replace tapes 1 and 2, take tapes 3 and 4 offsite
Week 9: Full backup to tapes 1 and 2
etc...
There will be 4 tapes total, 2 tapes per backup. amdump will be run
every 4 weeks.
The difficulty is that a full backup of our disks do not fit on one
tape. We can easily fit the excess in the holding space though. We are
willing to execute "amflush" after each backup to complete the full backup
on to 2 tapes. It's really not inconvenient when combined with sudo and
some staff shell accounts.
Aside from the weird crontab line, how would I configure Amanda to handle
this strategy? This is what I have right now (I know it's wrong because
it's not working at all):
dumpcycle 8 weeks
runspercycle 2
tapecycle 4 tapes
define dumptype comp-user-full {
comment "Non-root partitions on reasonably fast machines (full only)"
record yes
index yes
skip-incr yes
compress client fast
priority medium
}
amdump email returns the following message:
driver: WARNING: got empty schedule from planner
and all the disks get "SKIPPED."
I have a feeling "skip-incr" is not the right setting to use.
Anyone have any ideas?
Thank you for your help,
Cory Visi
Re: Archival tape backup configuration help
On Mon, Jul 08, 2002 at 04:57:07PM -0400, Cory Visi wrote:
> Ok, I have my daily tape backup set configured and working perfectly. Now I
> want to setup an archival (available for offsite storage) backup strategy.
> Here is how I want it to work:
>
> Week 1: Full backup to tapes 1 and 2
> Week 3: Take tapes 1 and 2 offsite
> Week 5: Full backup to tapes 3 and 4
> Week 7: Replace tapes 1 and 2, take tapes 3 and 4 offsite
> Week 9: Full backup to tapes 1 and 2
> etc...
>
> There will be 4 tapes total, 2 tapes per backup. amdump will be run
> every 4 weeks.
> The difficulty is that a full backup of our disks do not fit on one
> tape. We can easily fit the excess in the holding space though.
The limitation is not the size of the total backup.
The limitation is the size of the largest disklist entry. No SINGLE entry
in the disklist can span a tape. If you are using the same list (even if
in a different file and config) you already know each individual disklist
entry will fit onto a tape.
> Aside from the weird crontab line, how would I configure Amanda to handle
> this strategy? This is what I have right now (I know it's wrong because
> it's not working at all):
>
> dumpcycle 8 weeks
4 weeks
> runspercycle 2
1
> tapecycle 4 tapes
>
> define dumptype comp-user-full {
> comment "Non-root partitions on reasonably fast machines (full only)"
> record yes
Probably no so your dailies don't think a full was done and will
still do their own at the appropriate times.
> index yes
> skip-incr yes
Some suggest a dumpcycle of 0 to always force full.
> compress client fast
> priority medium
> }
>
> amdump email returns the following message:
> driver: WARNING: got empty schedule from planner
> and all the disks get "SKIPPED."
>
> I have a feeling "skip-incr" is not the right setting to use.
> Anyone have any ideas?
>
> Thank you for your help,
> Cory Visi
>
>
>>> End of included message <<<
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Archival tape backup configuration help
If I wanted to do something similar, but I didn't want to reuse the
tapes at all (I need to store each one for 7 years), how would I set
Amanda up to do that?
Thanks in advance!
Anthony
On Mon, 2002-07-08 at 12:53, Jon LaBadie wrote:
On Mon, Jul 08, 2002 at 04:57:07PM -0400, Cory Visi wrote:
> Ok, I have my daily tape backup set configured and working perfectly.
Now I
> want to setup an archival (available for offsite storage) backup
strategy.
> Here is how I want it to work:
>
> Week 1: Full backup to tapes 1 and 2
> Week 3: Take tapes 1 and 2 offsite
> Week 5: Full backup to tapes 3 and 4
> Week 7: Replace tapes 1 and 2, take tapes 3 and 4 offsite
> Week 9: Full backup to tapes 1 and 2
> etc...
>
> There will be 4 tapes total, 2 tapes per backup. amdump will be
run
> every 4 weeks.
> The difficulty is that a full backup of our disks do not fit on
one
> tape. We can easily fit the excess in the holding space though.
The limitation is not the size of the total backup.
The limitation is the size of the largest disklist entry. No SINGLE
entry
in the disklist can span a tape. If you are using the same list (even
if
in a different file and config) you already know each individual
disklist
entry will fit onto a tape.
> Aside from the weird crontab line, how would I configure Amanda to
handle
> this strategy? This is what I have right now (I know it's wrong
because
> it's not working at all):
>
> dumpcycle 8 weeks
4 weeks
> runspercycle 2
1
> tapecycle 4 tapes
>
> define dumptype comp-user-full {
> comment "Non-root partitions on reasonably fast machines (full
only)"
> record yes
Probably no so your dailies don't think a full was done and will
still do their own at the appropriate times.
> index yes
> skip-incr yes
Some suggest a dumpcycle of 0 to always force full.
> compress client fast
> priority medium
> }
>
> amdump email returns the following message:
> driver: WARNING: got empty schedule from planner
> and all the disks get "SKIPPED."
>
> I have a feeling "skip-incr" is not the right setting to use.
> Anyone have any ideas?
>
> Thank you for your help,
> Cory Visi
>
>
>>> End of included message <<<
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
RE: Archival tape backup configuration help
amanda@tape$ amadmin MyConfig no-reuse MyOffsiteTapeLabel-1
Amanda will keep the record of the backup, but never ask for the tape again.
It is essentially read-only.
You should add another tape to your rotation (with a new name) to replace
it.
> -Original Message-
> From: Anthony Valentine [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 12, 2002 5:08 PM
> To: Jon LaBadie
> Cc: Amanda Users
> Subject: Re: Archival tape backup configuration help
>
>
> If I wanted to do something similar, but I didn't want to reuse the
> tapes at all (I need to store each one for 7 years), how would I set
> Amanda up to do that?
>
> Thanks in advance!
>
> Anthony
>
>
>
> On Mon, 2002-07-08 at 12:53, Jon LaBadie wrote:
>
> On Mon, Jul 08, 2002 at 04:57:07PM -0400, Cory Visi wrote:
> > Ok, I have my daily tape backup set configured and working
> perfectly.
> Now I
> > want to setup an archival (available for offsite storage) backup
> strategy.
> > Here is how I want it to work:
> >
> > Week 1: Full backup to tapes 1 and 2
> > Week 3: Take tapes 1 and 2 offsite
> > Week 5: Full backup to tapes 3 and 4
> > Week 7: Replace tapes 1 and 2, take tapes 3 and 4 offsite
> > Week 9: Full backup to tapes 1 and 2
> > etc...
> >
> > There will be 4 tapes total, 2 tapes per backup. amdump will be
> run
> > every 4 weeks.
> > The difficulty is that a full backup of our disks do not fit on
> one
> > tape. We can easily fit the excess in the holding space though.
>
> The limitation is not the size of the total backup.
> The limitation is the size of the largest disklist entry. No SINGLE
> entry
> in the disklist can span a tape. If you are using the same list (even
> if
> in a different file and config) you already know each individual
> disklist
> entry will fit onto a tape.
>
> > Aside from the weird crontab line, how would I configure Amanda to
> handle
> > this strategy? This is what I have right now (I know it's wrong
> because
> > it's not working at all):
> >
> > dumpcycle 8 weeks
>
> 4 weeks
>
> > runspercycle 2
>
> 1
>
> > tapecycle 4 tapes
> >
> > define dumptype comp-user-full {
> > comment "Non-root partitions on reasonably fast machines (full
> only)"
> > record yes
>
> Probably no so your dailies don't think a full was done and will
> still do their own at the appropriate times.
>
> > index yes
> > skip-incr yes
>
> Some suggest a dumpcycle of 0 to always force full.
>
> > compress client fast
> > priority medium
> > }
> >
> > amdump email returns the following message:
> > driver: WARNING: got empty schedule from planner
> > and all the disks get "SKIPPED."
> >
> > I have a feeling "skip-incr" is not the right setting to use.
> > Anyone have any ideas?
> >
> > Thank you for your help,
> > Cory Visi
> >
> >
> >>> End of included message <<<
>
> --
> Jon H. LaBadie [EMAIL PROTECTED]
> JG Computing
> 4455 Province Line Road(609) 252-0159
> Princeton, NJ 08540-4322 (609) 683-7220 (fax)
>
Re: Archival tape backup configuration help
On Fri, Jul 12, 2002 at 05:28:12PM -0400, Bort, Paul wrote: > amanda@tape$ amadmin MyConfig no-reuse MyOffsiteTapeLabel-1 > > Amanda will keep the record of the backup, but never ask for the tape again. > It is essentially read-only. > > You should add another tape to your rotation (with a new name) to replace > it. > > > -Original Message- > > From: Anthony Valentine [mailto:[EMAIL PROTECTED]] > > Sent: Friday, July 12, 2002 5:08 PM > > To: Jon LaBadie > > Cc: Amanda Users > > Subject: Re: Archival tape backup configuration help > > > > > > If I wanted to do something similar, but I didn't want to reuse the > > tapes at all (I need to store each one for 7 years), how would I set > > Amanda up to do that? > > Paul, If one wanted to store every tape, i.e. never reuse one, is there a difference between setting each to "no-reuse" after it is written or setting tapecycle 99 (some huge number)? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax) duplicating list replies in personal email is superfluous
RE: Archival tape backup configuration help
I suggested no-reuse instead of upping tapecycle (which I expect would also work) because it covered the case of re-using some tapes and not others. I wasn't sure from the original message whether some tapes would be re-used or not. Your solution is definitely easier if none of the tapes in the rotation will ever be re-used. > Paul, > If one wanted to store every tape, i.e. never reuse one, is there a > difference between setting each to "no-reuse" after it is written > or setting tapecycle 99 (some huge number)? >
