Upcoming in R5D1, the backup and restore scripts now automatically sanity check the results. The builtin sanity checks are much faster than the original rough version posted here, and can also be run manually. The current versions, which can be found in /usr/local/bin are:

- mythbackup - backup and verify
- mythrestore - restore and verify
- checkbackup - verify that the current backup matches the system state.
- checkrestore - verify that the restored subset matches the system state.

- rollback.sh - A testing utility for discarding the newest backup, and rolling back to the previous one. Note that this does not do a restore. It just does a destructive "pop" on the backup stack. Caveat Utor!!!

Last edited by tjc on Wed Dec 27, 2006 7:46 pm, edited 1 time in total.

Not to be mean, but you keep asking questions on things that are already called out very clearly in the original documentation posting. You really need to go back and read that posting carefully. Do not skim, do not try to cherry pick, read it from start to finish and if necessary take notes.

All the files go into a single unified archive. This is the very first feature listed for the new backup.

There is a valid example backup.list and restore.list provided in the original posting.

It is explicitly called out that you need to start each entry in the lists with a './' (dot slash) rather than just a '/' (slash), and every directory or file name shown as part of the archive contents includes this to make sure the point is clear.

OK. I now see the"./" line at the end of a paragraph in your forum post. Sorry, I missed that.

But, my other question is not answered anywhere in your forum posting, so I'd still like it clarified. I'd like to backup all the scripts I've got sitting in /usr/src directory. All your examples call out 1 specific file and not all files of a certain filetype. See what I'm getting at?

So, what would a line in the backup.list file look like that would backup only the "xxxxx.sh" files in that directory? Is it?

Well, you asked about the scripts yes, but you never asked anything about wildcards until just now.

Frankly, I've never tried using them myself. I would recommend explictly listing the files you're interested in to avoid nasty accidents, however, I believe that the wildcards will work. The best way to find out for sure is probably just to try it.

- Boot from the CD as usual, but take option 6 (Exit) from the menu. This wil ask for confirmation then drop you to a command prompt.

- Type mount /dev/hda1 and hit enter. You can now access your root partition on /mnt/hda1. (Note from mihanson: this assumes your installation of R5B7 is on hda1. Substitute sda1 or whatever if you have a non-standard install)

This should copy the new backup script to your existing install. Just pop the CD and reboot.

Hello, I tried doing this, but with an R5D1 CD and wound up with all sorts of errors (which I can post if they will be helpful) when running mythbackup. With the changes in R5D1, does more need to be done to upgrade an R5B7 PC to the new backup scripts?

Yes. The backup/restore/check/rollback scripts now use a common library of variable and function definitions called "backupcommon", however, I don't really recommend taking that route. The R5D1 Upgrade Hints and the backup/restore page on the wiki include a simple command which will add the right tarball to an old style backup to effectively convert it to a new style backup. You can also get a script for checking the validity of the backup from the wiki page. Recommended reading for all your R5D1 upgrade preparations: http://mysettopbox.tv/phpBB2/viewtopic.php?t=11293http://www.knoppmythwiki.org/index.php?page=MythBackupAndRestoreHowTo

Please note that in R5D1 there is a known issue if you've enabled "logging to the database". The frontend can continue to log messages into the DB while the backup is running, thus changing the record counts the script uses to verify the success of your backup. To avoid this you may want to temporarily disable the logging, or shutdown the front end and run the mythbackup command in a shell session.

Otherwise if you get an error, open a shell window, run the checkbackup script, and if the only difference is the record counts in the "mythlog" DB table you can ignore them.

#----------------------------------------------------------------------------# Now to backup the other files, no fooling around, grab everything in the# list because you never know what you'll want, and we can always get clever# about what to restore later...

Interesting... It seems that if I delete all my mythconverg.sql* files from /myth/backup, but leave my savedfiles.tar.bz2* files, the problem with rollovers I mentioned in my previous post occurs. However, if I delete all my mythconverg.sql* and savedfiles.tar.bz2* files, effectively starting over with all my backup files, everything seems fine. Is there a reason why only deleting the db backups throws off the rollover portion of the script?

- The scripts are now more tolerant of restore.list and backup.list entries that don't start with "./", and nomalize them to the standard format.

- The default compression used for the backup files is now gzip. Both the saved files and mysql dump archives are compressed. This change was made for the ~20x speedup in backup times over bzip2. The size difference is insignificant compared to the size of other things in the /myth partition, but if you're truly obsessive-compulsive about disk space usage, running the gzip_to_bzip2.sh script will intelligently recompress things for you:

- To make the change above transparent, the scripts are now able to automatically detect and handle backup files that are either 1) compressed with gzip, 2) compressed with bzip2, 3) uncompressed. To avoid confusion you must make sure that there is only one form of the /myth/backup/savedfiles.tar* and/or /myth/backup/mythconverg.sql* files. This does not include the version numbered files (i.e. /myth/backup/*.[1-9]).

- The scripts now automatically verify that every backup and restore produced the intended results, and are fairly immune to "crying wolf". Any backup or restore failure messages should be investigated and possibly reported.

- There are now post restore fixups which get run automatically to upgrade certain files. This change simply formalizes and provides a standard location for upgrade edits which were being done elsewhere in the scripts.

I've done a lot of changes to the mythtv user since I did my first install, many upgrades ago. I get the feeling that by restoring my /home/mythtv I am missing out on some benefits of the newer builds. Even if I am not, I want to see "how the other half lives".

My idea is to

do a backup

create my own tar file of /home/mythtv

remove ./home/mythtv from savedfiles.tar.gz

boot from install CD and upgrade

Can you see any flaws in this? Will I get the same /home/mythtv as a clean install if I do that?

I then plan to restore things from my ~/.[bashrc|fluxbox|mozilla|mplayer|mythtv|screenrc|ssh|vim*] as I encounter a need.

I'm also wondering if I need to use some defaults from /etc also. I think I may pull the ./etc/profile & ./etc/bash.bashrc files from savedfiles.tar.gz. I know that in order to get my ~/.bashrc to load after my upgrade to R5E#, I had to do some serious horking around.

I've not seen a "what you are missing out on by not doing a clean install" thread. Is there a discussion on this? Is it worth having?

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum