a cautionary tale w/ successful recovery

[Andrew Sackville-West]

Hi all, mildly off-topic, perhaps.

Due to a cascading series of errors on my part yesterday, I managed to
not only wipe over my partition table, but also overwrite enough data
in the actual disk to prevent reasonable recovery of the partitions
with such tools as gpart.

I could recover /boot, and /swap, but the lvm-hosted remaining portion
of the system was hosed, mostly because I couldn't accurately locate
the partition. Maybe if I'd been a little smarter about it, I could
have, but I didn't know, until too late, what exactly to look for. So,
after much gnashing of teeth and rending of clothing, I decided to
reinstall.

Now mind you, this is the first reinstall on this machine (a very loose
description considering it's had three motherboards, two disks and
various and sundry parts swapped) since 2004.

Installation was, of course, fairly painless using the daily-build
business card image of squeeze. I had a couple of problems when
partitioning, but got it sorted out after a reboot to properly re-read
the partition table.

So here is the real success part of the story: my backups worked! I
had weekly backups of /etc and daily backups of /home. Since I'd not
done any work of consequence in about 24 hours, I had not lost data!
Restoring was a simple matter of copying over from the backup server,
fixing up a couple of permissions and moving on.

Lessons learned:
1) don't do risky things in DOS 6.22 when tired... you can't trust
DOS to behave in a consistent manner (maybe)

2) keep a copy of the boot sector lying around (on another machine!!)
3) keep a copy of dpkg --get-selections lying around

Now, I know bot 2) and 3), but hadn't really ever bothered to do
it. It's *possible* that 2) could have saved me from reinstalling, but
it still would have required significant work to get everything going
again.

3) is just a convenience really. I have a pretty good idea of what
packages I use on a daily basis are, but there are always random
things one forgets and they'll probably crop up routinely over the
next couple of months.

Anyway, I just wanted to share that. And for all those who think they
don't need backups... you're so wrong. I am truly grateful that I had
good ones and the recovery went well.

A

[Andrew Reid-4]

On Sunday 01 November 2009 17:57:49 Andrew Sackville-West wrote:

>
> So here is the real success part of the story: my backups worked! I
> had weekly backups of /etc and daily backups of /home. Since I'd not
> done any work of consequence in about 24 hours, I had not lost data!
> Restoring was a simple matter of copying over from the backup server,
> fixing up a couple of permissions and moving on.
>
> Lessons learned:
> 1) don't do risky things in DOS 6.22 when tired... you can't trust
> DOS to behave in a consistent manner (maybe)
>
> 2) keep a copy of the boot sector lying around (on another machine!!)
> 3) keep a copy of dpkg --get-selections lying around

  Congratulations!  

  If it were within my power, I'd award you the Order of the Clue,
the one with the *nice* ribbon.
 
  For the sysems I back up at work, we do the dpkg --get-selections
thing, but I've never kept a copy of the boot sector -- that's an
excellent idea.

                                -- A.
--
Andrew Reid / reidac@...


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Rob Owens-2]

On Sun, Nov 01, 2009 at 02:57:49PM -0800, Andrew Sackville-West wrote:

> Hi all, mildly off-topic, perhaps.
>
> Due to a cascading series of errors on my part yesterday, I managed to
> not only wipe over my partition table, but also overwrite enough data
> in the actual disk to prevent reasonable recovery of the partitions
> with such tools as gpart.
>
> I could recover /boot, and /swap, but the lvm-hosted remaining portion
> of the system was hosed, mostly because I couldn't accurately locate
> the partition. Maybe if I'd been a little smarter about it, I could
> have, but I didn't know, until too late, what exactly to look for. So,
> after much gnashing of teeth and rending of clothing, I decided to
> reinstall.
>
> Now mind you, this is the first reinstall on this machine (a very loose
> description considering it's had three motherboards, two disks and
> various and sundry parts swapped) since 2004.
>
> Installation was, of course, fairly painless using the daily-build
> business card image of squeeze. I had a couple of problems when
> partitioning, but got it sorted out after a reboot to properly re-read
> the partition table.
>
> So here is the real success part of the story: my backups worked! I
> had weekly backups of /etc and daily backups of /home. Since I'd not
> done any work of consequence in about 24 hours, I had not lost data!
> Restoring was a simple matter of copying over from the backup server,
> fixing up a couple of permissions and moving on.
>
> Lessons learned:
> 1) don't do risky things in DOS 6.22 when tired... you can't trust
> DOS to behave in a consistent manner (maybe)
>
> 2) keep a copy of the boot sector lying around (on another machine!!)
> 3) keep a copy of dpkg --get-selections lying around
>
> Now, I know bot 2) and 3), but hadn't really ever bothered to do
> it. It's *possible* that 2) could have saved me from reinstalling, but
> it still would have required significant work to get everything going
> again.
>
> 3) is just a convenience really. I have a pretty good idea of what
> packages I use on a daily basis are, but there are always random
> things one forgets and they'll probably crop up routinely over the
> next couple of months.
>
> Anyway, I just wanted to share that. And for all those who think they
> don't need backups... you're so wrong. I am truly grateful that I had
> good ones and the recovery went well.
>

A couple good utilites I've used in situations like these are testdisk
and photorec.  Photorec can recover files even if there is no partition
table (it won't know the filename, but it will tell you the file type).

-Rob


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andrew Sackville-West]

On Sun, Nov 01, 2009 at 07:20:23PM -0500, Rob Owens wrote:

> On Sun, Nov 01, 2009 at 02:57:49PM -0800, Andrew Sackville-West wrote:
> > Hi all, mildly off-topic, perhaps.
> >
> > Due to a cascading series of errors on my part yesterday, I managed to
> > not only wipe over my partition table, but also overwrite enough data
> > in the actual disk to prevent reasonable recovery of the partitions
> > with such tools as gpart.
> >
> > I could recover /boot, and /swap, but the lvm-hosted remaining portion
> > of the system was hosed, mostly because I couldn't accurately locate
> > the partition. Maybe if I'd been a little smarter about it, I could
> > have, but I didn't know, until too late, what exactly to look for. So,
> > after much gnashing of teeth and rending of clothing, I decided to
> > reinstall.

[...]

> A couple good utilites I've used in situations like these are testdisk
> and photorec.  Photorec can recover files even if there is no partition
> table (it won't know the filename, but it will tell you the file type).

to be clear, I was able to see portions of file systems and actually
found all of / using gnu-fdisk's "Rescue" feature. I was able to mount
and fsck it and it checked out okay. But that fs was buried in an lvm
partition *and* it couldn't find other filesystems. Since I run
multiple lv's in lv to hold the system, it wasn't much use... having /
without /usr and /var is not really that great.

gpart found /boot and /swap(not much use), but /boot was corrupted pretty
badly. It did *not* find anything in the lvm partition, though I got
tired of waiting for it, so maybe it would have eventually.

This has caused me to rethink the use of lvm on this system. Although
I like the flexibility, I'm not so sure it's not just better to use
one large partition for everything.

What I discovered is that though it might have been possible to
recover, it was certainly easier and ultimately less stressful to just
reinstall and restore from backup.

A

[Andrew Sackville-West]

On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote:

> On Sunday 01 November 2009 17:57:49 Andrew Sackville-West wrote:
>
> >
> > So here is the real success part of the story: my backups worked! I
> > had weekly backups of /etc and daily backups of /home. Since I'd not
> > done any work of consequence in about 24 hours, I had not lost data!
> > Restoring was a simple matter of copying over from the backup server,
> > fixing up a couple of permissions and moving on.
> >
> > Lessons learned:
> > 1) don't do risky things in DOS 6.22 when tired... you can't trust
> > DOS to behave in a consistent manner (maybe)
> >
> > 2) keep a copy of the boot sector lying around (on another machine!!)
> > 3) keep a copy of dpkg --get-selections lying around
>
>
>   Congratulations!  
>
>   If it were within my power, I'd award you the Order of the Clue,
> the one with the *nice* ribbon.

:)

>  
>   For the sysems I back up at work, we do the dpkg --get-selections
> thing, but I've never kept a copy of the boot sector -- that's an
> excellent idea.

It turns out it would not have really helped in this situation because
of writes in other parts of the disk, but in other, slightly less
catastrophic situations, it would have been useful.

If I had managed to understand what was going on between the part
where the MBR got munched and other bits started flying out to the
disk, it would have worked to just rewrite the MBR and reboot.

A

[celejar]

On Sun, 1 Nov 2009 14:57:49 -0800
Andrew Sackville-West <andrew@...> wrote:

...

> 3) is just a convenience really. I have a pretty good idea of what
> packages I use on a daily basis are, but there are always random
> things one forgets and they'll probably crop up routinely over the
> next couple of months.

Yeah, you'll remember wpasupplicant the first time that you're at a
location that requires access to an encrypted network ... (Been there,
done that :/)

> Anyway, I just wanted to share that. And for all those who think they
> don't need backups... you're so wrong. I am truly grateful that I had
> good ones and the recovery went well.

AOL!

Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Kroeger]

>> I am truly grateful that I had
> > good ones and the recovery went well.
 
For those of us not as Debian educated, you know like me who use Arno-iptables- firewall instead of Shorewall, I like Terabyte's image for Linux v.2. and if you're squeamish about paying a fee for this you can have the v.1.99 with less options for free. You can run it from its own partition or a CD as a boot disk for imaging any partition including the MBR on your choice of detachable or internal storage, the network version (v.2x) goes beyond the local host.

--
C.


--


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Johannes Wiedersich]

Andrew Sackville-West wrote:
> On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote:
>>   For the sysems I back up at work, we do the dpkg --get-selections
>> thing, but I've never kept a copy of the boot sector -- that's an
>> excellent idea.

I guess the 'state of the art' way of recording a list of installed
packages, nowadays is

# aptitude -F "%p" search '~i!~M' > package-list

You can then just install like

# aptitude install $(cat pacage-list)

dpkg --get-selections does not distinguish between packages installed
manually or automatically, so that information is lost on the reinstall.
 The search pattern just looks for packages that were installed
manually. The install will automatically install all dependencies.

> If I had managed to understand what was going on between the part
> where the MBR got munched and other bits started flying out to the
> disk, it would have worked to just rewrite the MBR and reboot.

There is also testdisk to help recover the mbr for you... Worked for me
once.

--
Johannes

Three nations have not officially adopted the International System
of Units as their primary or sole system of measurement: Burma,
Liberia, and the United States.

http://en.wikipedia.org/wiki/Si_units


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Boyd Stephen Smith Jr.-3]

On Tuesday 03 November 2009 10:38:41 Johannes Wiedersich wrote:

> Andrew Sackville-West wrote:
> > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote:
> >>   For the sysems I back up at work, we do the dpkg --get-selections
> >> thing, but I've never kept a copy of the boot sector -- that's an
> >> excellent idea.
>
> I guess the 'state of the art' way of recording a list of installed
> packages, nowadays is
>
> # aptitude -F "%p" search '~i!~M' > package-list
>
> You can then just install like
>
> # aptitude install $(cat pacage-list)
>
> dpkg --get-selections does not distinguish between packages installed
> manually or automatically, so that information is lost on the reinstall.
>  The search pattern just looks for packages that were installed
> manually. The install will automatically install all dependencies.

However, because of OR dependencies (i.e. using the '|' character), it might
install *different* packages to satisfy dependencies.  Your saved
configuration files won't work with those packages.

Some combination of dpkg --get-selections and aptitude search '~M' should be
able to save both "all installed packages" and "all automatically installed
packages", and some combination of dpkg --set-selections, aptitude markauto,
and aptitude install should be able to restore them.
--
Boyd Stephen Smith Jr.           ,= ,-_-. =.
bss@...             ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/            \_/

[Paul E Condon]

On 20091103_114547, Boyd Stephen Smith Jr. wrote:

> On Tuesday 03 November 2009 10:38:41 Johannes Wiedersich wrote:
> > Andrew Sackville-West wrote:
> > > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote:
> > >>   For the sysems I back up at work, we do the dpkg --get-selections
> > >> thing, but I've never kept a copy of the boot sector -- that's an
> > >> excellent idea.
> >
> > I guess the 'state of the art' way of recording a list of installed
> > packages, nowadays is
> >
> > # aptitude -F "%p" search '~i!~M' > package-list
> >
> > You can then just install like
> >
> > # aptitude install $(cat pacage-list)
> >
> > dpkg --get-selections does not distinguish between packages installed
> > manually or automatically, so that information is lost on the reinstall.
> >  The search pattern just looks for packages that were installed
> > manually. The install will automatically install all dependencies.
>
> However, because of OR dependencies (i.e. using the '|' character), it might
> install *different* packages to satisfy dependencies.  Your saved
> configuration files won't work with those packages.
>
> Some combination of dpkg --get-selections and aptitude search '~M' should be
> able to save both "all installed packages" and "all automatically installed
> packages", and some combination of dpkg --set-selections, aptitude markauto,
> and aptitude install should be able to restore them.

My suggestion is:

# aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' > package-list

followed by (without change except for fixing the missing "k" ;-)

# aptitude install $(cat package-list)

I haven't actually tested this. It is just what I think would work
from reading the aptitude documentation. By later today I may be able
to do some tests without trashing one of my systems. The theory is
that aptitude install understands that appending '+M' to a package
name is an indication that it is to mark the package as having been
installed to satisfy a dependency. The rest of the magic incantation
follows.

Question: Where would be a good place for the file, package-list,
within the Debian way? In /etc/apt/ ? Or /var/backups/ ? Elsewhere?

--
Paul E Condon          
pecondon@...


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Jason A. Spiro-2]

Paul E Condon <pecondon <at> mesanetworks.net> writes:

> My suggestion is:
>
> # aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' > package-list
>
> followed by (without change except for fixing the missing "k"  
>
> # aptitude install $(cat package-list)
>
> I haven't actually tested this. It is just what I think would work
> from reading the aptitude documentation. By later today I may be able
> to do some tests without trashing one of my systems. The theory is

[...]
>
> Question: Where would be a good place for the file, package-list,
> within the Debian way? In /etc/apt/ ? Or /var/backups/ ? Elsewhere?

I think it should go in /etc/apt.  Also, Aptitude should save an up-to-date
copy of the file every time you run an "aptitude install" or "aptitude upgrade"
command.

It would be wonderful if someone could test that:  it'd be difficult for me to
test, so I don't volunteer.  And then if someone could file a feature request
against aptitude asking them to implement this, or better yet, write a patch.

-Jason



--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul E Condon]

On 20091104_075158, Paul E Condon wrote:

> On 20091103_114547, Boyd Stephen Smith Jr. wrote:
> > On Tuesday 03 November 2009 10:38:41 Johannes Wiedersich wrote:
> > > Andrew Sackville-West wrote:
> > > > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote:
> > > >>   For the sysems I back up at work, we do the dpkg --get-selections
> > > >> thing, but I've never kept a copy of the boot sector -- that's an
> > > >> excellent idea.
> > >
> > > I guess the 'state of the art' way of recording a list of installed
> > > packages, nowadays is
> > >
> > > # aptitude -F "%p" search '~i!~M' > package-list
> > >
> > > You can then just install like
> > >
> > > # aptitude install $(cat pacage-list)
> > >
> > > dpkg --get-selections does not distinguish between packages installed
> > > manually or automatically, so that information is lost on the reinstall.
> > >  The search pattern just looks for packages that were installed
> > > manually. The install will automatically install all dependencies.
> >
> > However, because of OR dependencies (i.e. using the '|' character), it might

... snip ...

> > packages", and some combination of dpkg --set-selections, aptitude markauto,
> > and aptitude install should be able to restore them.
>
> My suggestion is:
>
> # aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' > package-list
>
> followed by (without change except for fixing the missing "k" ;-)
>
> # aptitude install $(cat package-list)
>
> I haven't actually tested this. It is just what I think would work

... snip ...

Now I have tested it, and, except for two nits, it works as very well.

Nit 1. An error of unrealistic expectation: I performed the test by
installing from the file packges-list into a different partition and
then overwriting the new /etc with a backup copy of the old
/etc. This, didn't work smoothly because the backup version of
/etc/fstab was _wrong_, really _wrong_ for root being in the new
partition.

Nit 2. sshfs didn't work on the new installation. There was a problem
with permissions and the fuse group. I checked groups for my user
account, and it showed me as being a member of the group fuse, but
something that I had not seen before, was wrong. This was fixed by
purging sshfs (which also removed fuse-utils, as was a hoped for
consequence of this suggestion) and installing it the normal,
interactive way. While this was being processed, I noticed that the
install script created the group fuse. Apparently, in the recreated
system, my user-name was a member of the fuse group, but the fuse
group did not actually exist. This lead to some disfunction in the
Debian Way.

Theory: Aptitude, when instructed to 'install fuse-utils+M', does just
that, namely 'install fuse-utils', followed by setting a boolean flag
to indicate automatic install. But it doesn't actually run any of the
install script of some other package, in this case sshfs, which does
actually create the fuse group.

If this theory is valid, then there can be other automatic installs that
are not properly handled by this suggestion, but don't happen to be part
of what I happen to have installed on my home system.

So, it would be nice if this were fixed in some general way. OTOH, it
might be a problem caused by fuse not being a 'regular' system group,
which would indicate changes, not in aptitude, but in the packaging of
fuse-utils.

Conclusion: I'm happy with this way of preparing a file that automates
the reconstruction of a whole host system. I'll be using it whether or
not my nits can be dealt with in some general way.
--
Paul E Condon          
pecondon@...


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Alex Samad]

On Fri, Nov 06, 2009 at 11:40:06AM -0700, Paul E Condon wrote:

> On 20091104_075158, Paul E Condon wrote:
> > On 20091103_114547, Boyd Stephen Smith Jr. wrote:
> > > On Tuesday 03 November 2009 10:38:41 Johannes Wiedersich wrote:
> > > > Andrew Sackville-West wrote:
> > > > > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote:
> > > > >>   For the sysems I back up at work, we do the dpkg --get-selections
> > > > >> thing, but I've never kept a copy of the boot sector -- that's an
> > > > >> excellent idea.
> > > >
> > > > I guess the 'state of the art' way of recording a list of installed
> > > > packages, nowadays is
> > > >
> > > > # aptitude -F "%p" search '~i!~M' > package-list
> > > >
> > > > You can then just install like
> > > >
> > > > # aptitude install $(cat pacage-list)
> > > >
> > > > dpkg --get-selections does not distinguish between packages installed
> > > > manually or automatically, so that information is lost on the reinstall.
> > > >  The search pattern just looks for packages that were installed
> > > > manually. The install will automatically install all dependencies.
> > >
> > > However, because of OR dependencies (i.e. using the '|' character), it might
> ... snip ...
>
> > > packages", and some combination of dpkg --set-selections, aptitude markauto,
> > > and aptitude install should be able to restore them.
> >
> > My suggestion is:
> >
> > # aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' > package-list
> >
> > followed by (without change except for fixing the missing "k" ;-)
> >
> > # aptitude install $(cat package-list)
> >

[snip]

> Conclusion: I'm happy with this way of preparing a file that automates
> the reconstruction of a whole host system. I'll be using it whether or
> not my nits can be dealt with in some general way.


can you please provide the steps you need for this

I have
aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' >>
/var/backups/package-list

but what about the package config information ??? how do I save that





--
"See, free nations are peaceful nations. Free nations don't attack each other. Free nations don't develop weapons of mass destruction. "

        - George W. Bush
10/03/2003
Milwaukee, WI

[Paul E Condon]

On 20091107_090413, Alex Samad wrote:

> On Fri, Nov 06, 2009 at 11:40:06AM -0700, Paul E Condon wrote:
> > On 20091104_075158, Paul E Condon wrote:
> > > On 20091103_114547, Boyd Stephen Smith Jr. wrote:
> > > > On Tuesday 03 November 2009 10:38:41 Johannes Wiedersich wrote:
> > > > > Andrew Sackville-West wrote:
> > > > > > On Sun, Nov 01, 2009 at 07:08:00PM -0500, Andrew Reid wrote:
> > > > > >>   For the sysems I back up at work, we do the dpkg --get-selections
> > > > > >> thing, but I've never kept a copy of the boot sector -- that's an
> > > > > >> excellent idea.
> > > > >
> > > > > I guess the 'state of the art' way of recording a list of installed
> > > > > packages, nowadays is
> > > > >
> > > > > # aptitude -F "%p" search '~i!~M' > package-list
> > > > >
> > > > > You can then just install like
> > > > >
> > > > > # aptitude install $(cat pacage-list)
> > > > >
> > > > > dpkg --get-selections does not distinguish between packages installed
> > > > > manually or automatically, so that information is lost on the reinstall.
> > > > >  The search pattern just looks for packages that were installed
> > > > > manually. The install will automatically install all dependencies.
> > > >
> > > > However, because of OR dependencies (i.e. using the '|' character), it might
> > ... snip ...
> >
> > > > packages", and some combination of dpkg --set-selections, aptitude markauto,
> > > > and aptitude install should be able to restore them.
> > >
> > > My suggestion is:
> > >
> > > # aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' > package-list
> > >
> > > followed by (without change except for fixing the missing "k" ;-)
> > >
> > > # aptitude install $(cat package-list)
> > >
>
> [snip]
>
> > Conclusion: I'm happy with this way of preparing a file that automates
> > the reconstruction of a whole host system. I'll be using it whether or
> > not my nits can be dealt with in some general way.
>
>
> can you please provide the steps you need for this
>
> I have
> aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' >>
> /var/backups/package-list
>
> but what about the package config information ??? how do I save that

This hack is _not_ a full backup system. You need a backup system that
backs up all your personal files _and_ all the system files that you
have configured. The genesis of this thread was the question: what to
do, in addition to that, in order to record what software packages
were installed? For that question, I have heard several suggestions,
e.g. dpkg --get-selections.

Most backups systems that I have looked at don't specify what,
exactly, should be backed-up. I believe that the great bulk of files
in /var are not important to me when I am rebuilding a crashed
system. Or rebuilding a system that I have so messed up, that I have
decided to do a reinstall. So, I think that putting something that is
important to me in /var is not so good an idea. The suggestion to put
packages-list in /etc/apt seems better to me. But, on my systems, I
actually put it into /root/package-list, because I am already doing a
full backup of /root, daily.

For rebuilding, after doing a netinstall, I use
# aptitude install $(cat /db2/<...>/root/package-list )
where <...> is a long string to where the backup files are actually kept.

Then I overwrite /etc with:
# cp -a /db2/<...>/etc/* /etc

This overwrites all the config stuff that was just built by aptitude
with the original config from that file backup on disk /db2

But it doesn't quite work, as was explained earlier.

--
Paul E Condon          
pecondon@...


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Alex Samad]

On Fri, Nov 06, 2009 at 04:40:36PM -0700, Paul E Condon wrote:
> On 20091107_090413, Alex Samad wrote:
> > On Fri, Nov 06, 2009 at 11:40:06AM -0700, Paul E Condon wrote:
> > > On 20091104_075158, Paul E Condon wrote:
> > > > On 20091103_114547, Boyd Stephen Smith Jr. wrote:


[snip]

> >
> > can you please provide the steps you need for this
> >
> > I have
> > aptitude -F "%p %M" search '~i' |tr -s ' '|sed 's/ A$/+M/' >>
> > /var/backups/package-list
> >
> > but what about the package config information ??? how do I save that
>
> This hack is _not_ a full backup system. You need a backup system that
> backs up all your personal files _and_ all the system files that you

yeah currently do a rdiff-backup / backupserver::/system so I get every
thing, but I am guessing saving package listing and package conf - not
etc stuff - but the stuff that you are asked when installing a package
(debconf I think) would be good to backup.

Even though I have every thing backed  up, I would still like to
re-install and reconfig as needed

> have configured. The genesis of this thread was the question: what to
> do, in addition to that, in order to record what software packages
> were installed? For that question, I have heard several suggestions,
> e.g. dpkg --get-selections.
>
> Most backups systems that I have looked at don't specify what,
> exactly, should be backed-up. I believe that the great bulk of files
> in /var are not important to me when I am rebuilding a crashed
> system. Or rebuilding a system that I have so messed up, that I have
> decided to do a reinstall. So, I think that putting something that is
> important to me in /var is not so good an idea. The suggestion to put
> packages-list in /etc/apt seems better to me. But, on my systems, I
> actually put it into /root/package-list, because I am already doing a
> full backup of /root, daily.
>
> For rebuilding, after doing a netinstall, I use
> # aptitude install $(cat /db2/<...>/root/package-list )
> where <...> is a long string to where the backup files are actually kept.
>
> Then I overwrite /etc with:
> # cp -a /db2/<...>/etc/* /etc
>
> This overwrites all the config stuff that was just built by aptitude
> with the original config from that file backup on disk /db2
>
> But it doesn't quite work, as was explained earlier.
>

--
"The legislature's job is to write law. It's the executive branch's job to interpret law."

        - George W. Bush
11/22/2000
Austin, TX