Hi Kern,
Perhaps it didn't drop the database but it did drop each table -- otherwise,
how can the example from the Catalog Maintenance chapter of the manual work?
mysqldump -f --opt bacula bacula.sql
mysql bacula bacula.sql
rm -f bacula.sql
because of the --opt parameter in the
Hello,
Am 07.09.2005 schrieb Philipp Steinkrueger:
Hi Kern,
Perhaps it didn't drop the database but it did drop each table --
otherwise, how can the example from the Catalog Maintenance chapter of the
manual work?
mysqldump -f --opt bacula bacula.sql
mysql bacula bacula.sql
rm -f
Philipp Steinkrueger [EMAIL PROTECTED] wrote:
if you dump the database and reload it into the server,
there are chances that the autoincrement values are renumberd.
i cant find a reference for that at mysql.com at the moment,
but i am pretty sure i've read something like this and the problem
Hi,
Masopust Christian wrote:
Hello all,
my configuration is as follows:
- Director and Storage at FedoraCore 3 system, Database Mysql 4.1.12,
Backup to Disk (2 RAIDs with 2.6TB)
- Clients are Linux, SUNs, Windows
Bacula run fine till last weekend. Since Sunday every job fails with
Hello,
Am 06.09.2005 schrieb Arno Lehmann:
Hi,
Masopust Christian wrote:
Hello all,
my configuration is as follows:
- Director and Storage at FedoraCore 3 system, Database Mysql 4.1.12,
Backup to Disk (2 RAIDs with 2.6TB)
- Clients are Linux, SUNs, Windows
Bacula run fine
