Author |
Message |
cahlfors
|
Posted: Fri Jan 18, 2008 12:15 pm |
|
Joined: Tue Jan 23, 2007 1:38 pm
Posts: 251
Location:
Sweden
|
Yes, I did something really stupid causing the root partition to become unreadable.
Sadly, I didn't backup before working with it. However, I have a working daily automatic backup of the database created using this script that a friendly fellow submitted in this forum:
Code: #!/bin/sh #Dumps the mythconverg database - daily backup #Keeps the last 7 days DAY=($(/bin/date +%u)) DUMPFILE="mythbe_$DAY.sql.gz" /usr/bin/mysqldump -u mythtv -pmythtv mythconverg -c > /myth/backup/$DUMPFILE exit 0
To correct the problem, I have now used upgrade, but the restore part doesn't seem to restore. I suspect an unexpected file name of the dumped database to be the error. Can I just rename it to something and rerun restore from the front end? What's the expected name?
Hopefully, I can at least get back my database. I have copies of all the config files I've created, but realize I will have to redo the setup work for lirc, MythWeb etc, etc.
Cheers,
/Chris
_________________ LinHES R8.6.1 BE: AMD64X4, 4GB, Hauppauge usb tuners FE1: Gigabyte F2A85X-UP4, nVidia GT640 FE2: Gigabyte GA-MA69GM-S2H, AthlonX2 4850E 2.5 GHz, 1GB, ASUS GEFORCE 7200GS 256MB FE3: Asus Eeebox410
Last edited by cahlfors on Sat Jan 19, 2008 8:35 am, edited 1 time in total.
|
|
Top |
|
 |
jmckeown2
|
Posted: Fri Jan 18, 2008 2:55 pm |
|
Joined: Sat Sep 02, 2006 9:17 am
Posts: 359
|
If you created using mysqldump directly, then try mysql to pull it back in,
cat /myth/backup/$DUMPFILE > mysql --user=mythtv --password=mythtv mythconverg
Good luck.
Alternately You can try to rename it to "mythconverg.sql" Then gzip it; you should then have mythconverg.sql.gz. The knoppmyth restore may work then.
You may want to look to using mythbackup in the future. It also backs up vital files from the root partition.
|
|
Top |
|
 |
tjc
|
Posted: Fri Jan 18, 2008 6:27 pm |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
Covered in both of these sticky posts:
Taking advantage of the enhanced backup and restore scripts
R5F27 Hints - Please read before installing! (this includes upgrading)
Both tell you the expected names and locations of the files.
Also, as jmckeown2 notes you really should use the mythbackup script in the future. It was specifically designed to gather all of you critical configuration data in one convenient package, and includes a multi-backup rollover queue intended to support daily or weekly backups, so that if there is something wrong with the most recent backup(s) you can use an older one.
|
|
Top |
|
 |
cahlfors
|
Posted: Sat Jan 19, 2008 8:33 am |
|
Joined: Tue Jan 23, 2007 1:38 pm
Posts: 251
Location:
Sweden
|
Thanks guys!
I was able to use the KnoppMyth restore. It turned out that the sqldump wasn't compressed despite its file name and the restore failed. A misplaced option in the script, it turned out.
Now everything but MythWeb works. I set that up after I did the last manual backup. As a side effect of this exercise, the system got upgraded to *F27 and new knowledge has been added to the brain (oh,yeah, that hurt!).
For now on I'll make sure to do the following:
* add to the backup.list and restore.list anything I add along the way
* run a manual backup often (I'll write that 100 times on the board)
* run a manual backup after any crash or reset, since I learned it fixes the sql tables (one before the crash would be nice, too  )
What started this mess is that the root file system got full soon after an inadvertent reset of the machine and fsck. Using du with various options, I was unable to locate any particularly large files and the du sum did not indicate a full file system. Hence I suspected something wrong with the file system. I've seen other people report similar observations in this forum. Thinking that an fsck on the root file system would give me an indication of this and planning to answer "no" to any changes if it did, I just ran it. That's when I discovered the first thing it did was to "recover" the journal. Goodbye file system!
I think there is an option to fsck to perform a "dry run" without any changes - just reporting what it would do. That's what I intended to do. It's amazing how fast a system can be hosed.
To avoid inadvertent restarts in the future, I plan to break out my backend and put it along with the file server, where there is a UPS and no impatient family members using the standard Windows cure (hit reset) when there is any hesitation in performance.
On the bright side, the family members expressed how much they missed MythTV the couple of days it's been gone. Although I have a standard DTV box for backup - "it's not the same", they say.
THANKS all KnoppMyth volunteers and helpful supporters!
Cheers,
/Chris 
_________________ LinHES R8.6.1 BE: AMD64X4, 4GB, Hauppauge usb tuners FE1: Gigabyte F2A85X-UP4, nVidia GT640 FE2: Gigabyte GA-MA69GM-S2H, AthlonX2 4850E 2.5 GHz, 1GB, ASUS GEFORCE 7200GS 256MB FE3: Asus Eeebox410
|
|
Top |
|
 |
jmckeown2
|
Posted: Sat Jan 19, 2008 9:05 am |
|
Joined: Sat Sep 02, 2006 9:17 am
Posts: 359
|
Quote: run a manual backup often (I'll write that 100 times on the board)
I'm pretty sure you can cron mythbackup,
How did you invoke your backup script before? change it to /usr/local/bin/mythbackup
|
|
Top |
|
 |
tjc
|
Posted: Sat Jan 19, 2008 11:08 am |
|
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location:
Arlington, MA
|
The only thing to beware of on that count is that the backup _does_ shutdown both the DB and the backend. So you have to make sure that your cron job doesn't conflict with any scheduled recordings. (Making a backup without shutting down those servers will not reliably produce good, internally consistent, results, and a bad backup can be worse than none at all.)
As for the supplemental lists, read the "Taking advantage of ..." how-to and the hints linked above carefully for information on what is already backed up and restored, and avoid redundancy. Including things twice will produce scary warning messages.
|
|
Top |
|
 |
mjl
|
Posted: Sat Jan 19, 2008 4:13 pm |
|
Joined: Sun Jun 12, 2005 10:55 pm
Posts: 3161
Location:
Warwick, RI
|
Hi,
Because I forget things at times, I have my KM box remember for me. I modified my halt button in the menu to call a halt-control.sh script that I place into the /usr/bin. Also when I click on a button, I hate to wait & wonder if the button was really activated. This cures most of the issues from my view point.
Code: #<code> #!/bin/bash killall xterm sudo killall mythfrontend& echo "Starting Backup, followed with shutdown" > /tmp/ver echo "This may take a few minutes...." >> /tmp/ver export DISPLAY=:0 export FONT="-adobe-helvetica-bold-*-*-*-34-*-*-*-*-*-*-*" cat /tmp/ver | osd_cat --delay=180 --font=$FONT --color=yellow --shadow=2 --pos=middle --align=centre& festival --tts /tmp/ver >/dev/null (play /usr/share/sounds/beg.wav) > /dev/null sleep 1 sudo /usr/local/bin/mythbackup killall osd_cat (play /usr/share/sounds/end.wav)& > /dev/null sudo halt #<end code>
Do watch for line wrap if someone wishes to try it. When I hit the button, it cleans house dropping back to the desktop, presenting a message for confirmation and then does what it needs to do. Backup, shutdown and power off. (Rarely used unless upgrading  )
I also have a similar script for reboot, just no backup.
Mike
|
|
Top |
|
 |
cahlfors
|
Posted: Sun Jan 20, 2008 2:05 pm |
|
Joined: Tue Jan 23, 2007 1:38 pm
Posts: 251
Location:
Sweden
|
Quote: How did you invoke your backup script before? Code: cron.daily
The script comes from the MythTV Wiki http://www.mythtv.org/wiki/index.php/User_Manual:Periodic_MaintenanceQuote: Making a backup without shutting down those servers will not reliably produce good, internally consistent, results, and a bad backup can be worse than none at all.
It sounds reasonable when you say it, but I really thought the automatic sqldump was reliable.
Well, I guess I'll let the script run and start doing manual backups, too. The dumps have different names, so they don't overwrite one another.
Maybe I should also take a look at the powerdown technology. It seems to be able to foresee any scheduled recordings. That's what it would take to automate the reliable built-in backup
Cheers,
/Chris 
_________________ LinHES R8.6.1 BE: AMD64X4, 4GB, Hauppauge usb tuners FE1: Gigabyte F2A85X-UP4, nVidia GT640 FE2: Gigabyte GA-MA69GM-S2H, AthlonX2 4850E 2.5 GHz, 1GB, ASUS GEFORCE 7200GS 256MB FE3: Asus Eeebox410
|
|
Top |
|
 |