on Thu, Apr 05, 2001 at 05:16:25PM -0400, Cyanide Morgoth Calcuterm ([EMAIL PROTECTED]) wrote: > >===== Original Message From "Karsten M. Self" <kmself@ix.netcom.com> ===== > >on Thu, Apr 05, 2001 at 04:28:45PM -0400, Cyanide Morgoth Calcuterm > ([EMAIL PROTECTED]) wrote: > > > >> > - OK, you don't have a backup system. Buy a DAT drive for $400 and a > >> > handful of tapes. Or a CDW or CDRW system. But I'd prefer tape. > >> > >> $400 USD cost more than my computer cost > > > >Completely irrelevant. > > > > I wish I could say that. I'm a student I don't have extra cash.
This and your other responses are largely irrelevant. Bordering on
tiresome. System administration, like economics, is about the
allocation of scarce resources (time, money, hardware, available
storage, memory, processing power) to providing services you desire.
Complaining that you have no money, value your data greatly, and don't
have time to resolve your issues *doesn't* address the problem at hand
or suggest a solution path.
It does outline your constraining parameters. You're playing the
typical game of youth: wanting everything (I know, I was there once).
You're going to have to sacrifice something toward your objectives.
Deal with it.
And, if your time and safety net are so constrained, stop mucking around
in system directories as root destroying things wantonly and whinging
about it on mailing lists.
> > What are the minimum technical requirements to accomplish your
> > archival and recovery objectives?
>
> Technical requirements? I know exactly how to do all the fancy things
> with tape archival it's just that I don't have the money or the
> hardware both of which are needed for the process.
You fail to understand. What minimum requirements would satisfy your
fundamental data/system recovery needs? That's the question. Read the
references pointed to previously, several are pointed to.
> >There may be less expensive alternatives than a DAT drive, discussed in
> >the references below, however I strongly recommend the technology.
>
> And I will do just that when I have a computer that dosn't cost less
> than the drive.
You really do have problems with fundamental comprehension. As stated,
the value of the computer is irrelevant. It's the value of what's on
it, and its replacement/recovery cost.
> >Disaster recovery requires preparation. You appear to be unprepared.
> >You have several options, none of them are going to be painless. You
> >have to determine what recovery path is best for you.
>
> Actually I have a really easy option assuming that it's packaged
> right. Basically I assumed (rightly) that all I need are those files.
> Now I have a system with debian 2.1 which had the various files in
> /bin but they weren't compatable and so therefore had to think of
> other options. Then I thought if unstable had a simple tgz file with
> the base OS then maybe I could easily extract it in winzip and then
> just copy over the files without fuss or muss.
>
> Unfortunately some wonderfully gifted person decided that unstable
> didn't need a disk section or even a base install and so therefore I
> don't have access to this easy medium. If only I have access to a
> clean system with the files in /bin that is on x86 and that is running
> the version of libc that unstable works under (2.2.x if I remember
> correctly) then it would work. Unfortunately sometimes I believe in
> bad luck and I believe that things never work properly the first time.
You're making little to no sense. Debian is a package-based system with
various dependencies. There is no single set of files which are found
under /bin in all systems -- this is a function of the packages you have
installed.
I passed you a list of packages which contribute files found in /bin on
my system. You can find a similar list under /var/lib/dpkg which by
your reports has not (yet) been damaged on your system.
- status: a list of installed packages with descriptions and status.
- info/*.list: packages with files listed. Your /bin files will be
found by grepping through here. Reinstall said files.
You can browse and extract Debian .deb files with mc (midnight
commander), also gmc (GNU Midnight Commander) and Nautilus. The format
itself is a "shar" shell archive, and it's possible to extract the
contents of the archive using commonly available, basic, GNU/Linux /
Unix / POSIX tools (this is a significant departure of the .deb format
from the RPM file format, which requires specific RPM libraries or
utilities to access it). Virtually any rescue/boot GNU/Linux system
(Tom's Root/Boot, the LinuxCare BBC, the Debian install disk), a
proprietary Unix system, or a Unix toolkit for a foreign OS (such as
UWIN or Cygwin for Legacy MS Windows) should provide you the tools you
need to:
- Get a list of files you need to recover for /bin from
/var/lib/dpkg/info/*.list.
- Download the appropriate Debian packages via ftp or http methods
from an archive.
- Extract the archives.
- Copy the relevant binaries to /bin
You'll probably want to run a global verify and reconfigure of
everything to ensure you've got your system fully up to date. Frankly
I've nevery fscked my system up enough to know what's required to do
this, I'd recommend digging through the apt documentation, apt-get and
dpkg man pages. A summary to list might be informative.
> >You're encouraged to look over my documents on system partitioning
> >(which relates to isolating system, local, and variable data), and
> >backup strategies:
> >
> > http://kmself.home.netcom.com/Linux/FAQs/partition.html
> > http://kmself.home.netcom.com/Linux/FAQs/backups.html
>
> How pray tell do you expand a system? Suppose I outgrow my partition
> on /home? or better yet outgrow some vital area that I say need more
> space for programs that I want that debian decides to install like
> /usr/bin or /usr/lib or others.
I use destructive repartitioning. Archive data. Repartition disk.
Restore data. I've got a bit more flexibility these days having a
network and several spare GB of networked storage. My last
repartitioning occured without ever fully disabling the box I was
modifying, and largely relied on stashing data locally rather than to
tape or remote storage. But I *had* multiple redundant backups in the
event anything went wrong. I did have to move a couple of archives over
the net.
> It seems to me that it works better if you have a system you
> administer by hand rather than a system that is automated by packages
> like debian or redhat. Non destructive repartitioning is the only
> cure and last I checked there were no utilities that worked for ext2
> partitions that allowed for nondestructive dynamic repartitioning of
> any sort. Not to mention that I ususally partition my disk so there is
> no room (or cannot affort to let it sit idle for too long).
_What_ works better?
parted is a tool for manipulating partition tables, including resizing
partitions. Note that *any* partition resizing tool can cause data
loss, and backups are very strongly recommended in any event. My own
preference for destructive methods is based on the principle that I'm
familiar with the tools, prefer the low-level control they provide, and
am more confident of my ability to recover in the event of problems with
the process.
Your partitioning scheme is your own issue. Again, it appears you're
trying to satisfy mutual conflicting requirements. You are *going* to
run into problems with this attitude, I guarantee you. Scale your goals
and methods to your resources.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
pgpdVMre3HA8T.pgp
Description: PGP signature
