On Sat, 2 Dec 2000, John R. Jackson wrote:
> >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.
There's an X/OPEN backup API which is already implemented by many of the
DB vendors. Certainly Oracle's RMAN and Informix's onbar use it to back up
tablespaces/dbspaces and log files to backup management systems. I can't
for the life of me remember what it's called at the moment.
> 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 :-).
A daily database export to a filesystem FIFO with compress on the other
side of it. Much much easier than reloading entire databases but on a test
system I think i'd agree with you.
> 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.
Oh, OK, I was thinking of tar only. I don't use dump for compatibility
reasons.
> 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.
Rather than specifying the actual backup utility, Amanda could specify a
backup *type* which is the type of data to expect back from a user
specified backup script.
