empty mysql backups

[qzaidi]

If a .my.cnf file already exists, backup-manager will create an empty sql file (and a 14 byte bz2 file if compression is on). This happens because it uses the --defaults-extra-file option from mysql, and this overrides everything except the ~/.my.cnf. The failure is not reported anywhere (not even in the verbose mode).

It should not fail silently - if mysqldump failed, $PIPESTATUS could be used to determine failure.

[amnesic]

I just verified my SQL backup and I confirm this important problem here too. (all my backup was 14 byte only !)

[keskad]

This looks like serious problem :-)

[DynamoEffects]

Similar problem here, except that the MySQL backups are completely empty and there is no .my.cnf in the root home directory.

If I run backup-manager manually, it works fine. When executed through a cron job, even as root, the database backup is empty.

[HgAlexx]

Same here, mysql export are empty. Running version 0.7.9-3 on Ubuntu Server 10.04.3 LTS. The same config was working before, nothing change (except of course a package update)

[kissifrot]

Code was updated in devel branch. Could you guys check it out if the issue is still there?

[HgAlexx]

Hi,

Sorry for the delay, but unfortunately I cant make any update of this kind on the server having the issue.

I have reproduce the issue with version 0.7.9-3 (last package available) on the lastest ubuntu server (11.10).

Default backup-manager install, default .conf file with one change: export BM_ARCHIVE_METHOD="tarball" to export BM_ARCHIVE_METHOD="tarball mysql"

I will try using the last code but I not sure I success to deploy it :)

Bye.

[HgAlexx]

It seams that the last code has the same issue. Sorry.

[DynamoEffects]

What's odd about this is that the MySQL backup uploaded to S3 is complete, but the one stored locally is 0 bytes.

[HgAlexx]

I am using ftp method to upload, the file on the ftp are the same as in /var/archives, size = 14 octets for bz2 files.

[kissifrot]

Okay thanks for the feedback, I'll try to work on this ASAP.

[gzarkadas]

I just created a .my.cnf putting there the mysql login password and then run backup-manager. All went well. Since the 14 byte filesize was a problem every time I did not managed to connect to the database backend (both mysql and postgresql), I tend to believe it is just an issue of inability to connect to the database server due to configuration errors and not a misfunction of backup-manager.

Using 0.7.10.1 release for the testing.

[DynamoEffects]

Georgios, what's odd is that a full MySQL backup was uploaded to S3 but locally it only stored a 0byte file. Since the S3 backups are what I really care about, I haven't looked into it much further but if I find a solution I'll post a patch.

[Anselme]

Do you have something like $$ in your pasword ? I had to echap the weirds caracters with a \

[Ricoux]

Hello, I've already the same issue but I don't have a .cnf file in my /root (using with root user). I've tryed on debian with versions 0.7.8 and 0.7.10.1. Run manually or not has the same effect.

Any ideas?

[HugoPoi]

I've the same probleme on debian with the version 0.7.9

[moafred]

Is there any solution ? Have the same with 0.7.9-debian1

[HugoPoi]

I have the solution, backup-manager work like a charm but it doesn't recognize a fail mysql backup with mysqldump command. So everybody in this issue should check with the mysqldump command if it doesn't return a error. In my case the database was corrupt and mysqldump didn't want to make a backup.

[kissifrot]

Dev branch ersion should stop on mysqldump error. I'll try to find time to do more check(s), but as you saw I didn't have free time lately :(

[HugoPoi]

it's not a big problem, sysadmins must check their backups mainly if they have a weird size.

[moafred]

@HugoPoi I've tried a mysqldump for each database and there was no errors or warnings :s

[jloosfelt]

Same problem here, I have no ~/.my.cnf for the root user which runs the cron. The password had weird characters, I also tried to escape them. The mysqldump command works for me, it just tells me

-- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly.

I agree that sysadmins must check their backups, but what should I do now to make them work? By the way, my gz backups are 20 bytes not 14.

[harmv]

this is quite a big issue... failing silently is not acceptable for any app, but especially for a backup app.

[NetJump]

Same problem over here. And it's not solved yet!!! This report is open since July the 4th of 2011! Thats quite a huge time for such a bad bug in my opinion.

backup-manager 0.7.10.1-2 Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux

[kissifrot]

Can you try with the mentionned patch?

[NetJump]

Yep, that worked. It showed me an error this time. BUT (Now it comes)... This is not the main problem.

My backup-manager worked fine for years now. Anytime with the same login combination and there has never changed anything.

And some weeks before the mysql backup stopped working from one day to the other. There has to be an update which is causing the main problem.

And here my suggestions what the actual problem is: Backup-manager loads the mysql login from "/root/.backup-manager_my.cnf". In there is a WRONG PASSWORD! And the wrong password is even in there wehen I delete this file and let backup-manager recreate it. So I searched for a reason... And I found one... If I write the correct login into this file, everything is working very nicely. But as soon as backup-manager recreates this file, there is a wrong password in there again. And I found out, that this problem is not existing if I am using a password without the "$" in it. So there is a problem in backup-manager. If the password is containing a "$", the password is not beeing fully written to the cnf file.

Example: Password in "/etc/backup-manager.conf" file: myultra$specialpassword Password in "/root/.backup-manager_my.cnf" file: myultra

So everything after the "$" got cut away in the "/root/.backup-manager_my.cnf" file. Can you fix that? Or is there maybe already a fix for this?

EDIT: Can give you teamviewer access onto a putty console for error analysis. Just ask for if interested.

EDIT2: The backup-process is now stopping after creating the tarball. Backup-manager simply freezes at: myuser@myserver:~# backup-manager -v Getting lock for backup-manager 5315 with /etc/backup-manager.conf Cleaning /var/backup-manager/archives Using method "tarball". /var/backup-manager/archives/backup-webserver_.20150708.master.tar.gz: ok (7099M, 7872d865dfa4e4358b6e32f5a6053f5d) -> At this point backup-manager freezes and does nothing more. Config part: "export BM_ARCHIVE_METHOD="tarball mysql". -> If I try "tarball" only, everything is working fine. If I try "mysql" only, everything is working fine too. But if I combine those two, backup-manager freezes whitout any other action (so no ftp upload at all).

Thank you & best regards!

[mvrueden]

I am not sure if this helps, but: I experienced this error when I changed the user and password to create the backups. As mentioned above deleting the file /root/.backup-manager_my.cnf and re-run backup-manager solved the problem for me. In general I would very much appreciate it if backup-manager were a bit more chatty.

[bluemanos]

The issue happening also to me :/

I'm login as root on the server. When I'm using root mysql privileges in /etc/backup-managere.conf than the mysql dumps are ok. Any other mysql user cant create dumps - even if he have full privileges.

Second thing - every time I'm running the backup-manager, it saying that he creating the .backup-manager_my.cnf file, but it is never created.

[kissifrot]

Does the problem still occur with 0.7.11?

[yverry]

You have a /root/.my.cnf. This .my.cnf override backup-manager config.

1- remove your .my.cnf 2- (the best) add section in your /root/.my.cnf:

[mysqldump]
user=<youruser>
password=<yourpassword>

run again backup-manager, enjoy !

[deogracia]

"asty one ...

change my root password couple of weeks ago, and wonder why I got 14byte sql.bz2 file I totaly forgot I manualy created a ~/.my.cnf file.

Once I delete it, compressed archive got a reasaonbly size...

Thanks @yanntech and others! you save my week!

[RaspbianFrance]

Hey here, just have the same trouble on our own backup of howtoraspberrypi.com. It's finally pretty simple, simply check in your /etc/backup-manager.conf if you have a $ in your password. In this case, simply add an \ before it, and this should fix this issue !