Hi,
Thanks for the quick response.
> This only occurs when you specify databases and you have compress=no,
> mysqld isn't running or mysqdump doesn't exist. This is a pretty
> unique combination of events!
Please note that this happened to me (and I tested again) with
"compress=yes". I refer to "sql.gz" files in my original report. But
yes, it looks like it only happens when you specify databases and one of
the other two conditions.
> Backupninja is designed with the expectation that the backups that you
> are making of your databases are being backed up to another system or
> another disk using one of the handlers such as rdiff, duplicity, rsnap,
> dup, etc. It is expected that the mysqldumps that are made in your
> backup directory are not the end of the backup, but rather this are
> shipped off in the remainder of the process. Although I agree its a bad
> situation to be in to create a zero-byte mysql dump, I am hesitant to
> agree that this is causes serious data loss. Using that logic, you could
> claim that backupninja causes serious data loss when you delete
> everything from your database and then you do a backup of an empty
> database, or likewise.
According to the guidance provided by "reportbug", "critical", due to
serious data loss, seems to be the correct choice. "serious" bugs are
for data loss of "unimportant" data or data that can be recovered
*without* resorting to a backup. If mysql corrupts my database and dies
(a plausible scenario that in fact was my problem), then the mysql dumps
are overwritten with empty files, I better hope I did the smart thing
and have daily backups that allow me to go back at least 1 day before
the catastrophe.
The scenario above is much different than the *intentional* act of
deleting all of my data from the database...in that case backupninja
would just be copying exactly what I put in--garbage in, garbage out.
Thanks again,
Joel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
