Backup Central

Hi guys,

I've successfully setup an Amanda server to backup some two Linux
servers and one Windows server to a SDX-300C 35GB SCSI tape.

Doing so and figuring out all of the little quirks has been a trying
experience, and the FOM is in a horrendous state.

That said, I still have more backup needs I want to use AMANDA with, and
hopefully I'll be able to update the FOM based on that.

I have 10 tapes running daily with runspercycle 9 and dumpcycle 2 weeks.

I want to have another cycle running every other Friday (two weeks), but
cron doesn't seem to be able to handle that. I posted to the
fedora-list and someone posted this[1] script (yes, yes, I know it's
not ready for submission yet. It needs modification before it's useful
for what I want...). I was thinking someone would have something based
on the "at" command, but this looks ok too.

It would be nice to have some contributed scripts for these typical
types of things AMANDA is used for.

I also want to backup to a filesystem several windows machines, but I'd
like to find a way to avoid the inevitable locked files that may be found.

I'm thinking of saving backup images to a remote server over a VPN
connection (and possibly after encrypting the backup data also). Has
used AMANDA in a setup like this?

Anyway, I plan on using my shell and perl scripting skills to help when
I can, and especially fix the documentation!

Mike
[1]
if test -f /etc/foo
then
rm -f /etc/foo
else
touch /etc/foo
exit 0
fi

On Tue, Jul 20, 2004 at 05:13:46PM -0700, Mike Fedyk wrote:
I have 10 tapes running daily with runspercycle 9 and dumpcycle 2 weeks.

Any chance of changing that to a 1-week cycle with 5 runspercycle?
In general, you want to have at least 2 cycles' worth of tapes, just
in case. Having one extra tape is good, since it keeps you from ever
overwriting your most recent backup of anything, but it still doesn't
give much protection against bad backups.

I want to have another cycle running every other Friday (two weeks), but
cron doesn't seem to be able to handle that.

`date +%U` gives you the week number in the year. If there's an easy way
to test whether a number is even or odd in the shell, then that could be
used to run something from cron on only even/only odd-numbered weeks,
although there's still the possibility for anomalies at the end of the
year (week 52 -> week 00 is two evens in a row - but if this happens
every year, testing the evenness/oddness of year + week number would
solve it)...

OK, somewhat convoluted way to do it:

[ $(echo "$(date +\%U) \% 2" | bc) == 0 ] && /usr/local/sbin/backup-script

This will run /usr/local/sbin/backup-script on all even-numbered
weeks. Change the 0 to 1 for odd weeks. Also note that the %s need
to be backslash-escaped to prevent cron from intepreting them as
newlines/command separators. (Only tested in bash, but, IIRC, the $()
syntax works in csh and vanilla sh also.)

Anyone have a simpler even/odd week test?

On Wed, Jul 21, 2004 at 10:55:00AM -0700, Mike Fedyk wrote:
Jon LaBadie wrote:

On Tue, Jul 20, 2004 at 05:13:46PM -0700, Mike Fedyk wrote:


Hi guys,

...

I want to have another cycle running every other Friday (two weeks), but
cron doesn't seem to be able to handle that. I posted to the
fedora-list and someone posted this[1] script (yes, yes, I know it's
not ready for submission yet. It needs modification before it's useful
for what I want...). I was thinking someone would have something based
on the "at" command, but this looks ok too.

...

[1]
if test -f /etc/foo
then
rm -f /etc/foo
else
touch /etc/foo
exit 0
fi



Kidding right?

Actually no.

If you're going to do that, why not use "date +%U" instead? Then you
don't depend on jday, or is that only available in GNU date?

Some years have 52 Fridays, some 53. In the latter case you may
get extra dumps or miss some dumps.


I chose the temp file approach because it's simpler for the operator to
check and see if a file is there to know which command will run. I
suppose you could do the same with odd or even numbers though. With the
temp file it can use one script (call it "alternate"), and the time is
determined on how often it is called, so you could alternate monthly
just by calling it once a month.

The operator has to know where the name of the flag file,
where the flag file is located (I certainly would not recommend /etc),
whether it means the dump will be or won't be done,
and puts a lot of faith in the stability of a single file.

Really, it's just to get around deficiencies in cron's scheduling
capabilities.

The concept of running a wrapper from cron to decide if a program
should or shouldn't run is a tried and true approach. It is only
your test that I questioned.


Can we keep this on the list? Thanks.

--
Jon H. LaBadie jon < at > jgcomp.com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)

On Wed, Jul 21, 2004 at 05:49:48PM -0400, Jon LaBadie wrote:
In a 'real' bourne shell $(...) is not available, but `...` is.

And I was so sure it was the other way around... This was pointed out
to me offlist by someone else, too. Ah, well.

I actually wrote it using `...` first, but nesting them confused the
shell, so I changed it to something where the begin/end delimiters
were different.

However this can be simplified if you are working in a
posix-compatible shell. The math operators ((...)) provide
a return code of 0 or 1 depending on the zero/non-zero value
of the result. So you could do (ignoring cron required escapes)

(( $(date +%U) % 2 )) && ...

Very nice! Thanks!