[mythtv-users] How to backup progs before upgrade?

Cliff Avey makalu at ansae.com
Fri Aug 31 02:44:59 UTC 2007


That's excellent advice. I admit to being way to casual about backups. 
Hey when I started I had hardly anything recorded! I think I'll try to 
make a reasonable backup of everything but the video, which is on it's 
own filesystem.

In the meantime, I read the Makefiles to see what make install does, and 
I have another question, but I think I post a separate msg to keep this 
from going off-topic.

Thanks for your fast response and advise!

f-myth-users at media.mit.edu wrote:
>     > Date: Thu, 30 Aug 2007 22:04:41 -0400
>     > From: Cliff Avey <makalu at ansae.com>
>
>     > I've downloaded the mythtv 0.20.2 tarball and I'm building it now. 
>     > Everything is going smoothly as described. I've made a backup of my 
>     > mythconverg db. However, before I su and run make install, I'd like to 
>     > make a backup of my working old version (0.18). I've got scheduled 
>     > recordings almost every evening. If something goes wrong it would be 
>     > nice to be able revert to the old version until I can figure it out.
>
>     > I installed 0.18 from packages using the Mythtvology guide. Looks like 
>     > most everything is installed is /usr/bin. If I make a backup of 
>     > /usr/bin/myth*, will that back up everything that would get replaced by 
>     > running make install on v0.20? Or are there other programs in /usr/bin 
>     > or elsewhere, or config files anywhere that I should save before 
>     > installing 0.20?
>
> If you aren't making backups of your setup -anyway-, you're risking
> disaster from a bad disk.  My 0.18.1 setups only have a few hundred
> meg of system files and everything, including DB and a bunch of free
> space, fits in 3 gig or so; after all, it's basically an Ubuntu
> install, plus myth, plus a DB, plus some notes.  (All the video
> is of course on other disks and/or partitions.)
>
> What I'd recommend is that you rsync the contents of /, excluding dev
> lost_found media mnt proc sys, to some other disk.  Not only does this
> save you from having to figure out exactly what you need to preserve,
> but it can be an -invaluable- aid when something doesn't work and you
> say, "Geez, I wonder if there was some config file that changed or
> something else I'm forgetting about?"  You could even do "diff -r"
> between the two hierarchies, etc.
>
> Even better, of course, and what I often do when screwing around with
> complicated setups (and what I've been doing as I've tested things
> with Myth) is to boot single-user and then use dd to copy the entire
> partition to some other partition---or use dd & nc to copy it
> elsewhere on your network.  Then, no matter -how- badly you screw the
> pooch, you know you can slap the partition back and be back in
> business.  This is especially handy if you suspect that things like
> lirc or whatever are creating devices---or some symlinks to
> udev-created stuff, etc---that you're forgetting about or whatever.
> [Just make -sure- you don't get "if" and "of" reversed in the dd!  I
> haven't yet, but I -know- there will be a first time; I really, really
> miss the mechanical write-locks of the era of removable disk packs.]
>
> (I configured my myths w/3 partitions on each root disk, corresponding
> roughly to "previous", "current", and "next" versions, which I was
> anticipating might be entirely different OS releases as well; that
> way, I can just change grub's menu.lst and boot a different partition
> while I'm testing, with the ability to relatively rapidly recover if
> something goes wrong, and the ability to mount several of the
> partitions at once and compare files among them.  After all, they're
> each only 3-6G, and losing 10-20G compared to the enormous space
> required to store video is pretty much in the noise.  Whether your
> database lives in a separate partition or with the relevant myth
> version depends on the sorts of testing/rollback you might do; mine is
> on a separate spindle due to recording glitches (which of course
> didn't actually help until the don't-stall-the-copier-when-the-DB-
> is-locked patch came out, but still).  This means I either need a
> private, local-to-the-partition copy when testing, or I need to be
> careful to back it up just before a test, lest a newer Myth version
> send my DB on a one-way journey from which there is no recovery.)
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
>   


More information about the mythtv-users mailing list