[mythtv-users] How to backup progs before upgrade?
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
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
More information about the mythtv-users