Radoslaw,
Am 15.03.2013 um 16:08 schrieb Radosław Korzeniewski
rados...@korzeniewski.net:
I would give you any log you need ... but what logs are required?
What is your restore session? How do you select a jobid, how do you mark a
directory... etc...
I exactly did a
restore
select 5
Hi folks,
I've been warned re-importing an innodb mysql database was slow, but I
hadn't expected it to be *this* slow.
I'm dumping a catalog instance that is about 55GB in size (dump), but
the file table has 294GB in the database, so obviously there's a lot
of unused / deleted data in there.
Le 16/03/2013 10:54, Uwe Schuerkamp a écrit :
My question: Is there some way to optimize the catalog dump to make
the import faster, like maybe omitting indices and re-creating them
manually once the import has completed? Seeing the Path table also has
19GB, its import probably won't have
Hello,
2013/3/16 Christoph Litauer lita...@uni-koblenz.de
I think I found the reason:
While recovering my default config for replace was ifnewer. Changing
this to always recovers correct ownership and permissions ...
So, it is working as expected. Good.
But ... isn't this a bug? My
On Sat, Mar 16, 2013 at 1:46 AM, Jean-Gabriel Duquesnoy
d...@jgduke.dnsalias.com wrote:
Hi,
I have installed Bacula 5.0.2 on Debian 6.0.3 using the packages, I
did not compile and install Bacula from source code.
When going through the tutorial in the documentation, I keep getting
an error
Am Samstag 16 März 2013, 13:05:24 schrieb John Drescher:
On Sat, Mar 16, 2013 at 1:46 AM, Jean-Gabriel Duquesnoy
d...@jgduke.dnsalias.com wrote:
Hi,
I have installed Bacula 5.0.2 on Debian 6.0.3 using the packages,
I
did not compile and install Bacula from source code.
When going
Please find attached both files with passwords removed.
Hope this will help find the root cause of my problem.
Change the Device = /tmp in bacula-dir.conf to Device = FileStorage
# Definition of file storage device
Storage {
Name = File
# Do not use localhost here
Address = localhost
On 03/16/13 05:54, Uwe Schuerkamp wrote:
Hi folks,
I've been warned re-importing an innodb mysql database was slow, but I
hadn't expected it to be *this* slow.
The basic problem here is that mysqldump has not aged or scaled well,
and badly needs to be put out to pasture in favor of
On 03/16/13 06:18, Jérôme Blion wrote:
Le 16/03/2013 10:54, Uwe Schuerkamp a écrit :
My question: Is there some way to optimize the catalog dump to make
the import faster, like maybe omitting indices and re-creating them
manually once the import has completed? Seeing the Path table also has
