mythconverg *.BAK

[jamoody]

My database backup seems large at 130M compressed, 995M uncompressed. recordedseek.* are by far the largest tables
-rw-r----- 1 mysql mysql 254M May 30 00:35 recordedseek.MYI
-rw-r----- 1 mysql mysql 283M May 30 00:35 recordedseek.MYD
-rw-r----- 1 mysql mysql 284M May 24 09:10 recordedseek-190524092202.BAK
which make sense given an estimated 2256 hours of recordings (2725 programs, 4833G). My question is can I get rid of on recordedseek-190524092202.BAK to cut the size of the backup by about 1/3? What is the *.BAK created by?

Thanks.

[bill6502]

2nd question 1st. I'd see what your setting looks like:

Code: Select all

$ sudo grep -r myisam-recover /etc/mysql
/etc/mysql/mysql.conf.d/mysqld.cnf:myisam-recover-options  = BACKUP

Then search this page for the option: https://dev.mysql.com/doc/refman/5.5/en ... tions.html
If your setting includes BACKUP, that explains why the file is created. The cause is explained in the link.

1st question. Most likely OK. That is, if MythTV is recording/playing back OK, you don't want to recover
a single table. If you did, you'd loose any changes made, e.g. by new recordings. A better solution would
be to recover mythconverg from backup.

[jamoody]

Indeed BACKUP is specified:
$ sudo grep -r myisam-recover /etc/mysql
/etc/mysql/mysql.conf.d/mysqld.cnf:myisam-recover-options = BACKUP

So it looks like there was a recovery action on 5/24 and I did have a problem that day requiring me to do a full database restore from a backup. So that explains that.

MythTV has indeed been working fine since 5/24 (6 days) so I moved the *.BAK file (in case I needed it) and made a new backup of the database with no change in the zipped size, so apparently *.BAK is not included in the backup which makes sense. In any case, I now understand the situation and very much appreciate your help. Thanks.