Re: [Bacula-users] [Bacula-devel] Misc
Hello, On Thursday 01 March 2007 10:32:49 Kern Sibbald wrote: [...] 2. Doing a backup/restore from/to a FIFO (as defined in a FileSet resource) is supported and from my tests works perfectly well in Bacula 2.0.x. In some previous versions there were some problems, but they have long since been corrected. this item does indeed work very stable. I've been using this in production for exporting large Oracle databases (100+ GBytes each) once per week for about two years. I've never encountered stability issue with the FIFOS. :-) There was only one issue during restores (not a stability one though): the FIFO permissions were -rw--- and owned by root. Therefore the 'oracle' user was not able to read it for importing... though, I do not remember whether the reason was bacula or my own scripts?! Anyhow, bacula does not seem to wait long when there is nothing reading from the FIFO. So one must be quick with fixing the permissions... all my saying goes for 1.38.11 and previous versions. Unfortunately I can not tell for 2.0.x since I no longer have control over this installation... regards, Stephan - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] Misc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Ebelt wrote: Hello, On Thursday 01 March 2007 10:32:49 Kern Sibbald wrote: [...] 2. Doing a backup/restore from/to a FIFO (as defined in a FileSet resource) is supported and from my tests works perfectly well in Bacula 2.0.x. In some previous versions there were some problems, but they have long since been corrected. this item does indeed work very stable. I've been using this in production for exporting large Oracle databases (100+ GBytes each) once per week for about two years. I've never encountered stability issue with the FIFOS. :-) I would love, if you have the time, to write a brief mention about how this is done. Perhaps it could be posted somewhere (if it isn't already)? - -- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III |$| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5ughmb+gadEcsb4RAtGVAKCQY/3mcFsViPZaWtccLZWhKetBcQCffpS9 RBfUY1o7SAhUCjTAl6Bw+GE= =SUvR -END PGP SIGNATURE- - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] Misc
On Mar 1, 2007, at 6:50 AM, Ryan Novosielski wrote:
On Thursday 01 March 2007 10:32:49 Kern Sibbald wrote:
this item does indeed work very stable. I've been using this in
production for
exporting large Oracle databases (100+ GBytes each) once per week
for about
two years. I've never encountered stability issue with the FIFOS. :-)
I would love, if you have the time, to write a brief mention about how
this is done. Perhaps it could be posted somewhere (if it isn't
already)?
My experience with FIFO database dumps:
Basics: On backup, when Bacula encounters an explicit FIFO (with
readfifo=yes), It tries to read data from that FIFO until end-of-
file. On restore, if the FIFO doesn't exist, bacula creates it. It
then waits (1 min timeout) for something else to read from the FIFO.
If the mystery stranger connects, it just pours all the data it saved
back into the FIFO and moves on.
1. A 'gotcha': Your fileset must explicitly list the FIFOs as
individual files, they cannot be something it comes across via
recursion or regular expressions. One simple way of doing this for
all FIFOS in a directory is to run a command on the remote machine
that lists all fifos. Example fileset (replace directory name as
needed):
FileSet {
Name = DB FIFOs
Include {
Options {
readfifo=yes
}
# Documentation says fifos must be explicitly
# Mentioned. You can't just specify the directory
# That they'll all be created in, or readfifo
won't apply.
# This is a workaround for that limitation: Run a
script to list them.
File = \\|bash -c \find /tmp/bacula_fifos/ -type p
-maxdepth 1\
}
}
2. When Bacula hits the FIFOs, it will wait ~60 seconds on each file
for someone on the other end to start giving data (when Job=Backup)
or consuming it (Job=Restore). Thus you must start something in the
background to supply or take data from them.
RunScript {
# Uncomment appropriate command for desired effect, either backing
up, restoring to DB, or restoring to real files
#Command = /etc/bacula/launchwrapper.sh restoretodb /tmp/
bacula_fifos/
#Command = /etc/bacula/launchwrapper.sh restoretofolder /var/
eas_restore/tmp/bacula_fifos/ /var/eas_restore/bacula_fifodump/
#Command = /etc/bacula/launchwrapper.sh backup /tmp/bacula_fifos/
RunsWhen = Before
AbortJobOnError = yes
RunsOnClient = yes # BUG in early vers of Bacula 2.01, cannot use
uppercase Y in Yes for RunsOnClient.
}
RunScript {
# Clean out our FIFOs
Command = /etc/bacula/launchwrapper.sh clean /tmp/bacula_fifos/
RunsWhen = After
RunsOnSuccess = Yes
RunsOnFailure = Yes
RunsOnClient = yes
}
3. I had a bit of a problem with our set up, because we have many
databases per server which I wanted to handle individually. Spawning
lots of pg_dump processes writing to FIFOs (and waiting for Bacula to
come along) doesn't work, because you exhaust the connection pool and
only the first X databases will dump successfully.
So if anyone's interested, I have a python script which will actually
do non-blocking IO (gasp, shock) over the FIFOs, waiting until any
one of them can accept data and only *then* launching connecting to
the database to fill the FIFO. It will also do the converse for
restoring data back to the databases, noticing newly created FIFOs
(created by a Bacula restore job) in the directory and trying to grab
data from them. Note that this is definite overkill if you're okay
with doing one dump per server of all active databases.
--
--Darien A. Hager
[EMAIL PROTECTED]
-
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.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] Misc
Hi, On 3/1/2007 9:00 PM, Darien Hager wrote: On Mar 1, 2007, at 6:50 AM, Ryan Novosielski wrote: On Thursday 01 March 2007 10:32:49 Kern Sibbald wrote: this item does indeed work very stable. I've been using this in production for exporting large Oracle databases (100+ GBytes each) once per week for about two years. I've never encountered stability issue with the FIFOS. :-) I would love, if you have the time, to write a brief mention about how this is done. Perhaps it could be posted somewhere (if it isn't already)? My experience with FIFO database dumps: Basics: ... So if anyone's interested, I have a python script which will actually do non-blocking IO (gasp, shock) over the FIFOs, waiting until any one of them can accept data and only *then* launching connecting to the database to fill the FIFO. It will also do the converse for restoring data back to the databases, noticing newly created FIFOs (created by a Bacula restore job) in the directory and trying to grab data from them. Currently, I'm not interested but this sounds like areally great enhancement! You wrote that for PostgreSQL, but I suppose adapting it to other databases or whatever would not be too much of a problem, so I suggest you post it to the wiki at http://paramount.ind.wpi.edu/wiki/doku.php or mail to the list. I'm sure that script will be helpful to many users, and I suppose it could be added to the user-contributed examples in the source code. Note that this is definite overkill if you're okay with doing one dump per server of all active databases. Depends on the available dump space vs. database size... Arno -- --Darien A. Hager [EMAIL PROTECTED] - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- IT-Service Lehmann[EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] Misc
Torsdag 01 marts 2007 21:07 skrev Arno Lehmann: Hi, On 3/1/2007 9:00 PM, Darien Hager wrote: On Mar 1, 2007, at 6:50 AM, Ryan Novosielski wrote: On Thursday 01 March 2007 10:32:49 Kern Sibbald wrote: this item does indeed work very stable. I've been using this in production for exporting large Oracle databases (100+ GBytes each) once per week for about two years. I've never encountered stability issue with the FIFOS. :-) I would love, if you have the time, to write a brief mention about how this is done. Perhaps it could be posted somewhere (if it isn't already)? My experience with FIFO database dumps: Basics: ... So if anyone's interested, I have a python script which will actually do non-blocking IO (gasp, shock) over the FIFOs, waiting until any one of them can accept data and only *then* launching connecting to the database to fill the FIFO. It will also do the converse for restoring data back to the databases, noticing newly created FIFOs (created by a Bacula restore job) in the directory and trying to grab data from them. Currently, I'm not interested but this sounds like areally great enhancement! You wrote that for PostgreSQL, but I suppose adapting it to other databases or whatever would not be too much of a problem, so I suggest you post it to the wiki at http://paramount.ind.wpi.edu/wiki/doku.php or mail to the list. I'm sure that script will be helpful to many users, and I suppose it could be added to the user-contributed examples in the source code. Note that this is definite overkill if you're okay with doing one dump per server of all active databases. Depends on the available dump space vs. database size... I am reading this thread with interest and trying to understand. I thought that the databases would dump 'through' the FIFO directly to Bacula - thus eliminating the need for dump space - am I wrong here? Steen Arno -- --Darien A. Hager [EMAIL PROTECTED] - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- Regards Steen - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] Misc
Hello, On 3/2/2007 12:08 AM, Steen wrote: Torsdag 01 marts 2007 21:07 skrev Arno Lehmann: ... So if anyone's interested, I have a python script which will actually do non-blocking IO (gasp, shock) over the FIFOs, waiting until any one of them can accept data and only *then* launching connecting to the database to fill the FIFO. It will also do the converse for restoring data back to the databases, noticing newly created FIFOs (created by a Bacula restore job) in the directory and trying to grab data from them. Currently, I'm not interested but this sounds like areally great enhancement! You wrote that for PostgreSQL, but I suppose adapting it to other databases or whatever would not be too much of a problem, so I suggest you post it to the wiki at http://paramount.ind.wpi.edu/wiki/doku.php or mail to the list. I'm sure that script will be helpful to many users, and I suppose it could be added to the user-contributed examples in the source code. Note that this is definite overkill if you're okay with doing one dump per server of all active databases. Depends on the available dump space vs. database size... I am reading this thread with interest and trying to understand. I thought that the databases would dump 'through' the FIFO directly to Bacula - thus eliminating the need for dump space - am I wrong here? That's what can be achieved with a FIFO. The simpler solution is to dump to file and then back up that file. This is what the standard catalog backup script does, for example. Arno Steen Arno -- --Darien A. Hager [EMAIL PROTECTED] - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users -- IT-Service Lehmann[EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
