All of a sudden, my DB backup is failing. Nothing in the logs and "checkbackup" is as follows:

[root@mythserv /]# checkbackup

Checking for the existance of the backup tar file...
Using file /myth/backup/savedfiles.tar.gz
Backup tar file exists. Checking the compression...
Compression looks OK. Checking backup tar file contents...
Generating a list of the backup contents...
Generating a list of the directory contents...
Comparing directory versus backup contents...
Live and saved file lists match.

Checking for the existance of the DB dump file...
Using file /myth/backup/mythconverg.sql.gz
DB dump file exists. Checking the compression...
Compression looks OK. Checking DB dump contents...
Generating a list of tables and record counts in the DB dump...
Generating a list of tables and record counts in the live DB...
Comparing live versus saved tables...
48c48
< logging 34107
---
> logging 34020
Warning, table lists are not identical!

I have run myisamchk *.MYI|more to look for any errors - clean. The system is quiet - nothing running or recording (of course the scripts shut it down anyway...) so I dont understand how a DB dump and an almost immediate compare fails... Any suggestions of where to look are appreciated.

_________________
Backend server - 4.0 TB 3.0ghz dual core 6 gig RAM, nVidia 9400, Gigabyte GA-870A-UD3 MB, 2 HD-5500, 2 HD Homerun dual tuners, 3 frontend machines - LinHES 8.6.1

Hello

Sometimes the backups get CRC errors and that causes a mismatch between the old one and the new old. Go into your backup directory and move the files to a different folder. Then run the backup, you may have to run backup more that one time to get it work properly but is should work...

Thanks - I remember having this strange issue months ago but can't remember the cause or the fix... I moved the backup files (both savedfiles and mythconverg) and ran sudo mythbackup 5 times with the exact same results. I know this worked fine last week. Then, just for grins, I deleted the backup files and tried it again - still no good.

I have tried rebooting and replaying this. Suggestions? Without a good backup, I am vulnerable.

_________________
Backend server - 4.0 TB 3.0ghz dual core 6 gig RAM, nVidia 9400, Gigabyte GA-870A-UD3 MB, 2 HD-5500, 2 HD Homerun dual tuners, 3 frontend machines - LinHES 8.6.1

UPDATE - I cannot figure out why but for anybody else that has this problem... The trick seems to be that you delete the backups (myth/backups), reboot the machine, then run the backups again. I actually had to do that twice and now am back in business...

_________________
Backend server - 4.0 TB 3.0ghz dual core 6 gig RAM, nVidia 9400, Gigabyte GA-870A-UD3 MB, 2 HD-5500, 2 HD Homerun dual tuners, 3 frontend machines - LinHES 8.6.1

Here we go again... Same error

Checking for the existance of the backup tar file...
Using file /myth/backup/savedfiles.tar.gz
Backup tar file exists. Checking the compression...
Compression looks OK. Checking backup tar file contents...
Generating a list of the backup contents...
Generating a list of the directory contents...
Comparing directory versus backup contents...
Live and saved file lists match.

Checking for the existance of the DB dump file...
Using file /myth/backup/mythconverg.sql.gz
DB dump file exists. Checking the compression...
Compression looks OK. Checking DB dump contents...
Generating a list of tables and record counts in the DB dump...
Generating a list of tables and record counts in the live DB...
Comparing live versus saved tables...
48c48
< logging 26998
---
> logging 26877
Warning, table lists are not identical!

This seems to happen after several good backups. If I move or delete the backup files, reboot the machine then everything is fine for a while. This happens both manually running /usr/LH/bin/mythbackup or with a cron job. This is also on a machine that was upgraded from 7.2 (don't have a naked built 7.4).

Suggestions welcome...

_________________
Backend server - 4.0 TB 3.0ghz dual core 6 gig RAM, nVidia 9400, Gigabyte GA-870A-UD3 MB, 2 HD-5500, 2 HD Homerun dual tuners, 3 frontend machines - LinHES 8.6.1

OK - I have figured out what is going on. I am surprised this hasn't been noted before (if it has, I missed it...). Turns out the culprit is the logging table. When mythbackup stops the backend, the remote frontend machines complain and post a log entry. This happens after the database dump has occured (the database has the new log entry while the backup does not). As a result the test fails.

While it is safe to use that backup file, I will figure out a solution when time permits (am traveling at the moment).

_________________
Backend server - 4.0 TB 3.0ghz dual core 6 gig RAM, nVidia 9400, Gigabyte GA-870A-UD3 MB, 2 HD-5500, 2 HD Homerun dual tuners, 3 frontend machines - LinHES 8.6.1

I have the same "checkbackup" result, my logging table is completely different (see below). I just went through a clean install of R7.4 upgrading from R6.04 through the process and had been running smoothly for several weeks, but just last Wednesday my root partition was filled (warning came up in MythFrontend) and I noticed that a daily folder created in /var/log/YYYY-MM-DD was filling up the root partition. I wonder if these folder are left behind after the backup fails...

I am not an MySQL guru and am not sure how critical the logging table really is, but it is the only table with a warning.



Any help would be much appreciated.

Don't worry about it - that is just the logging table and the latest entries are from your running frontend(s)... When the backend goes away (backup stops the backend) the frontend complains and makes a log entry. If you had to reinstall, the log table is almost irrelevant... If you were to stop your frontend(s) before you do the backup there is no problem...

_________________
Backend server - 4.0 TB 3.0ghz dual core 6 gig RAM, nVidia 9400, Gigabyte GA-870A-UD3 MB, 2 HD-5500, 2 HD Homerun dual tuners, 3 frontend machines - LinHES 8.6.1

My hypothesis that the failed backup is causing the /var/log/2012-10-19, /var/log/2012-10-20, etc folders to no be deleted after a daily process (I assume a daily backup) is still causing me grief, the root partition is filling up daily because of this.

Hmm... I have that same failure every night (I suspect and my daily backups are working fine on both my production machine and my test machine. I suspect you have a different issue. If you read the script you will find nothing is done differently when the backup fails or it works...

What I don't understand is why you expect your current daily logs to be deleted... The system keeps several days worth of logs (will logrotate them off after several days). This is new in 7.04...

_________________
Backend server - 4.0 TB 3.0ghz dual core 6 gig RAM, nVidia 9400, Gigabyte GA-870A-UD3 MB, 2 HD-5500, 2 HD Homerun dual tuners, 3 frontend machines - LinHES 8.6.1

If it is normal to have several 1GB+ folders in /var/log/YYYY-MM-DD, I really need to get gparted going to expand my root partition.

I am only guessing these are temporary folders from the daily backup, I never saw my root partition grow this drastically overnight before moving to R7.4.

I also never had failed backups so consistently.

Not sure where else to look, which script is creating these /var/log/YYYY-MM-DD folders..

Thank you for your tips,

Whoa... My log folders are all less than 1 mg - way less. What is in your log? What is the large logfile (messages, kernal, frontend, backend)? And what is in it?

_________________
Backend server - 4.0 TB 3.0ghz dual core 6 gig RAM, nVidia 9400, Gigabyte GA-870A-UD3 MB, 2 HD-5500, 2 HD Homerun dual tuners, 3 frontend machines - LinHES 8.6.1

Thanks for your help, I am noticing that I have some rather large issues logged in log files (segfault in fuppes, I do not use it so I uninstalled, page flip errors logged in kernel, etc).

I will have to knock these out, one at a time, to avoid such large /var/log/ folders to be created.

Thank you all again for your great work on LinHES and support community.

Once I resolved these two bugs/issues, I was not having as much logging and large log files in the daily /var/log/YYYY-MM-DD folder

mythtv kernel: [58696.499010] [drm:intel_prepare_page_flip] *ERROR* Prepared flip multiple times
FIXED using https://bugs.launchpad.net/ubuntu/+sour ... bug/765813 and http://ubuntuforums.org/showthread.php?p=12034866
WARNING BEING LOGGED : "Unable to connect the the MySQL database to make needed changes to the LIRC socket. LIRC now uses /var/run/lirc/lircd and /dev/lirc is now obsolete. Update your MythTV settings to reflect this."
FIXED using : viewtopic.php?f=22&t=22687#p135080

Cheers