Re: [LAU] System Restore...

On Fri, May 2, 2008 at 6:52 PM, Ken Restivo <ken@email-addr-hidden> wrote:
> On Fri, May 02, 2008 at 01:27:49PM -0700, Russell Hanaghan wrote:
> > Hiya!
> >
> > So while Dave warmed up the crowd on the M$ related questions...
> >
> > ...and at the risk of being stoned in the Linux public square, is there
> > *any* form of the System Restore function that follws the model of the
> > ~other~ OS?
> >
> > One of my former direct reports, a wiz kid sys admin in the Bay area all
> > ready gave me the standard smart a$$ response; (Er, yeah! It's called a
> > "RE-INSTALL" ...lemme spall it for yah again!! ha ha ha ha) So after I got
> > up off the floor from gut level laughter.. (NOT!), I continue to believe
> > that for nooby converts, and maintaining it's customization ability via the
> > Linux model, would be a very useful tool!!!
> >
> > I have spent many hours recently setting up a custom audio distro that will
> > be remastered and available as a live CD. I'm no Linux sys admin...I figure
> > stuff out any way I can, take longer than most to get it just how I like
> > it....and then I say..hmm, just one more thing I'd like to change....and I
> > bjork the window manager or some such thing. To re-install at that point
> > kills MANY hours of fruitfull work and I'm old enough that I don't need
> > cliche lessons! :)
> >
>
> I do the following occasionally (not often enough):
> 1) I tar up the /etc directory
> 2) I do a "dpkg -l > status-of-installed-programs.log" to keep track of what software I've installed
> 3) I tar up the entire /usr/local directory tree into a separate tar file
> 4) I keep all my important data files in /home/music-projects, and I rsync that up to an external USB drive periodically for backups. I also keep any code or scripts in CVS and rsync that one up too periodically.
>
> A "system restore" is basically a reinstall from a distro CD. Then I use the status-of-installed-programs.log file to grep out a list of installed packages ("ii" status), awk to get the name of the packages, and then "apt-get install" them. Then I either gradually pick through the backed-up files in /etc and copy them over, or just wholesale replace the directory, depending on how much of a hurry I'm in. The data of course I've had rsync'ed onto a separate drive, so I just copy that one over.
>
> This is a long process, and I've been getting sufficiently paranoid lately to have obtained an extra 2.5" PATA drivein an external USB enclosure. I'm going to format it and copy over my entire drive so that I have a "hot spare". If my drive dies, I can just (hopefully) replace it with the new one and off I go.
>
> -ken
>
>
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
>

I gave up on dyne:bolic and pure:dyne because of out of date software,
but they are amazingly simple to back up.

You have a seperate disk image (a .dyne file) for each group of
applications, that get mounted in package specific directories under
/opt, so you end up with a path including entries like
"/opt/csound/bin:/opt/supercollider/bin:/opt/emacs/bin:/opt/firefox3/bin"
etc.
So if you need to upgrade a program, all of its dependancies
(libraries, helper apps, etc) are part of the same disk image.

Modifiable files are all in a disk image called dyne.nst. This is all
of your modifications, wheter you modify a file in /etc/ or your home
directory or /usr/bin or whatever, anything that is not identical to
the read only disk image you boot from is stored in dyne.nst and
merged through the magic of unionfs. If you run the "nest" application
which you initially ran to do your install, it copies all changes from
the read-only image to a new nest. Even if you already have a nest. In
other words it backs up all of your configuration and data, and
switching to the backup version is literally as easy as swapping the
backup file for the original.

Why I don't use dyne anymore: infrequent upstream updates, filling up
the nest file causes weird bugs, mounting /tmp as ramfs with only 64
megs of room (it could be my system was misconfigured, but it never
asked me whether /tmp should be ramfs and it never asked me how big it
should be) - lots of applications break when /tmp fills up. If it had
some better ways to deal with all the little virtual disks it uses
filling up, or if every linux app would learn to check if they are
filling up the file system they are using, and at the very least allow
a runtime configuration of temp file locations, dyne would be great (I
just recently figured out how to drop to single user and unmount /tmp
from ramfs and remount it on a reasonable sized partition, but found
no way to preserve this change across reboots).

I am using ubuntu now, but I do miss the realtime performance and
extreme ease of backup that dyne provided.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Sat May 3 08:15:04 2008