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

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Fri Aug 31 02:27:15 UTC 2007

    > 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.)

More information about the mythtv-users mailing list