Backup Central

Is there a known/standard way to get the jobid for the latest incremental backup for a client using
bconsole?
Or, does anyone have a tried and trusted method of their own?

I need the jobid for an automatic restore from one client to another, in a bconsole shell script that is
run immediately after successful completion of a daily incremental job.

The "current" backup is not ideal because that includes the most recent full backup. I need the
incremetal backup only (this is for servers with scheduled jobs for inc, diff and full backups).

One way I can think of would be to separate the diff/full and icremental jobs. I could create a job that
only does incrementals, and then use restore option 5. (select most recent backup for a client) in
the bconsole script.

(This is for off-site incrementals that are taken by Attix off of a W2k3 backup server. The W2k3
machine is the one to which the incrementals are "restored".)

Any suggestions would be most welcome.

Thanks,

Mark

Mark Tiramani
FREDO Internet Services
markjt < at > fr...

Hi,

On 3/12/2007 1:01 PM, markjt < at > fr... wrote:
Is there a known/standard way to get the jobid for the latest incremental backup for a client using
bconsole?

The only suggestion I have is parsing a query output. Or, alternatively,
directly access the catalog.

Or, does anyone have a tried and trusted method of their own?

I need the jobid for an automatic restore from one client to another, in a bconsole shell script that is
run immediately after successful completion of a daily incremental job.

The "current" backup is not ideal because that includes the most recent full backup. I need the
incremetal backup only (this is for servers with scheduled jobs for inc, diff and full backups).

One way I can think of would be to separate the diff/full and icremental jobs. I could create a job that
only does incrementals, and then use restore option 5. (select most recent backup for a client) in
the bconsole script.

That would not work, because for the Levels to reference each other,
they have to run through the same Job. I.e. it would create two
independent lists of backups if you separated the levels into two Jobs.


(This is for off-site incrementals that are taken by Attix off of a W2k3 backup server. The W2k3
machine is the one to which the incrementals are "restored".)

Any suggestions would be most welcome.

Looks like you, too, need copy jobs :-)

Do you backup to disk or to tape?

Backing up to disk, you could simply scp or rsync the volume files.

Of course, you could also use rsync to transfer the data to the off-site
system, independent of Bacula.

Arno

Thanks,

Mark

Mark Tiramani
FREDO Internet Services
markjt < at > fr...



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users < at > li...
https://lists.sourceforge.net/lists/listinfo/bacula-users

--
IT-Service Lehmann al < at > it...
Arno Lehmann http://www.its-lehmann.de

On 12 Mar 2007 at 21:26, Arno Lehmann wrote:

One way I can think of would be to separate the diff/full and icremental jobs. I could create a job that
only does incrementals, and then use restore option 5. (select most recent backup for a client) in
the bconsole script.

That would not work, because for the Levels to reference each other,
they have to run through the same Job. I.e. it would create two
independent lists of backups if you separated the levels into two Jobs.

Ah, thanks, I completely missed that point :)

Backing up to disk, you could simply scp or rsync the volume files.

Unfortunately that suggestion was already turned down. It is certainly the best way to retain backup
integrity IMO. But the off-site is outside of my control and the requirement is to have the actual
directory and file structure readily accessible, hence the "restore".

Of course, you could also use rsync to transfer the data to the off-site
system, independent of Bacula.

I agree, but again that idea fails in this case because of a lack of control I'm afraid.

Thanks anyhow, at least I know that I will not be waisting time with the output-to-file-and-parse-with-
Perl idea :)

Mark

Mark Tiramani
FREDO Internet Services
markjt < at > fr...