>I'm not totally familiar with Amanda so off the top of my head (and
>assuming we're using gnu tar) we could rename the gnu tar binary and write
>a script which wraps it ...
I should have mentioned that at the moment, this is how it would have
to be done, and that the real solution to this is the Amanda DUMPER-API,
yet to be implemented.
Another couple of thoughts from this morning. My Oracle person pointed
out another advantage to the big backup disk approach is that if they need
to do a recovery (which they do fairly often on the test systems), it can
be done immediately from there rather than bugging me to reload tapes.
I consider this a feature :-).
Now, I also fully realize the PUCC Oracle databases are probably not
really all that large. The backup images are a few GBytes. So the
script we're using may not be appropriate for larger sites.
One other advantage to the script we use is that it auto-detects new
(and removed) tablespaces. Again, because of all the testing we do,
that probably happens here more than in some other sites. It could be
handled by hand like any other disk, but it's kind of handy at the moment.
>The binaries are SUID root. It couldn't do the backup otherwise.
That is just not true. You do not need to be root to do backups.
I certainly do not, most Amanda users do not, and it's actually
recommended that you do not configure it this way. I have the raw disk
partitions in a group that the Amanda user is a member of and gave that
group read permission.
It's true some of the Amanda binaries are setuid root, but for the most
part that's so they can get a privileged port at startup. They then
drop their permissions.
One exception to this is runtar, which is setuid to get access to run
tar as root since it goes through the standard file system.
In the Oracle backup case, the GNU tar wrapper (or DUMPER-API script)
could probably be written setuid root (or use an external program) to
do whatever magic it has to to Oracle. But that's opening up a door
that would have to be very, very carefully coded.
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
