4/16 I use a 250GB WD disk with a single ext3 filesystem for making
backups, and it had a directory that containted all my system
snapshot backup directories. Yesterday, I discovered that the
directory has somehow turned into a text file containing the
content of /etc/login.defs. Is there a way to fix this without
removing all the hanging inodes, and thus removing all the backups?
I've heard people complain about ext filesystems. What reliable
filesystems do you recommend for use on a linux non-root filesystem
used for making backups?
\_ Sigh... ext2: suck0rz. ext3 = ext2 + pseudo journal = suck0rz with
pseudo journaling. I haven't used reiserfs enough to comment. I
have used xfs extensively on 2.2 and 2.4 boxes and in those
environments, xfs = suck0rz. I haven't ever used jfs or any of the
less common linux file systems. I've read the xfs on 2.6 has been
greatly improved but that's what they said for xfs on 2.4 right
before I lost 2 terabytes on 2.4 xfs. Using some psychotic reverse
logic, I'd recommend JFS or Reiserfs only because I haven't used
them yet and thus haven't had data loss on those FSs. ;-)
As far as your repairs go, try this:
1) dd the drive to another drive so you have a copy and then
do the following on that copy so you don't fuck up the only
copy you've got,
2) try a simple forced fsck on the copy and see what happens.
a second forced fsck and a reboot is worth the extra 30
seconds of effort if the first doesn't work just because,
3) if that doesn't work, there are a number of file recovery
utilities out there that *may* be able to recover some of
your back up files,
3b) if this is company data, there are professional data
recovery firms that *will* recover most, if not all, of
your lost data in this situation but they will charge you
anywhere between $20,000 and $80,000 and will not guarantee
success to any degree before they start.
4) good luck, I've been there, corrupt FSs suck. It sounds
like you don't have a second backup or anything on tape.
--motd storage guru
\_ Thanks. I don't have a second backup, but that seems like
a good idea. What's the best way to get 250GB on tape?
perhaps I'll get another 250 GB disk and firewire
enclosure.
\_ Your "VaporWare has no bugs" logic makes me suspicious of your
"storage guru" status, but what specific problems are you aware
of with ext3? -Not a Linux Fan, but using it.
\_ It should have been clear to anyone with basic English
reading comprehension skills exactly what I meant and why I
said that. However, for you I shall explain: since all of
the linux FSs I've used extensively have severe problems,
the only alternative when seeking a viable FS is to try
something unknown. It may have bugs. It may not. It should
have been clear from my own description of my own logic in
that regard that I wasn't vouching for FSs unknown to me in
extensive daily usage. As far as ext3 is concerned, it has
the same corruption problems as ext2 since it is little more
than ext2 with pseudo journaling kludge on. Once you get
over your core comprehension problem we can discuss my
qualifications vs. those of others on the motd for storage
guru status. I know of at least one person here who works
for Veritas. Other than that I'm unaware of and never seen
any exceptional knowledge from other motd posters. If you
prefer I can simply stop answering storage questions since
my flawed logic has so clearly tainted my advise in your
eyes. I don't care either way. -- msg
\_ What is wrong with ext3 other than "I have experienced
crashes"? Is it a performance problem with small files,
large files, filesystem corruption, metadata operation
problems, a problem with crash recovery due to async
operation, journaling strategy or implementation etc.
If you really were a file system guru, you would have
given feedback in these terms.
\_ Nonsense. I'm not a paid consultant for the motd.
Back to reading comprehension and context. Since the
op was concerned with FS corruption, what do *YOU*
think I was talking about? --msg
\_ What filesystem do you recommend?
\_ It depends on the purprose obviously.
I wouldn't recommend GPFS for a desk top
but for a high performance set up, GPFS
has an interesting design. Are you setting
up a mail spool? db? newsspool? Home p0rn
and warez store?
\_ One for snapshot-backups, another for
all-purpose sever, mail, web etc.
\- for my decent sized data operations,
say ~1tb, i use freebsd. minor vinum
problems but in general very solid,
even in the face of yank-the-cord-out
type crashes. for my "large data" either
we dont really care too much about
performance or reliability [batch processing
on scratch data] or we use sort of exotic
stuff that probably doesnt apply in your case.
andrew hume is a "large data" consumer who
doesnt like linux and is someone i'd trust
on blind faith, although that was a while ago.
i dont know if he has changed his mind with
linux 2.6. i'm not totally clear what his
problems where. i've seen linux corrupt data
for unknown reasons, bad memory, bad ethernet
driver in addition to crashes. the only major
problem i had on freebsd had to do with the
whole box crashing ... which may have had
something to do with a raid card [it looked
like a hw prob, but it wouldnt manifest when
the same hardware was running linux, knoppix]
etc. and dont get me started on about linux
block/char dev, caching, dumping issues.--psb
\_ you consider 1tb to be decent sized? uhm,
yeah, whatever. that's peanuts.
\_ Hear hear, ext2/3 is absolutely horrible in case of
catastrophic failure. It is exceedingly crash sensitive,
surprisingly even more so than UFS, which at least
attempts to appear crash resilient with it's fsck
hell. I just recently lost my umpteenth ext2/3 partition
last week on a new machine when an IRQ conflict
kept hanging the machine. -williamc
\_ Random question -- is it easy to get fbsd fs (any) to work
with linux?
\- why dont you install fbsd and run with linux application
compat options.
\_ Because fbsd is just a lot more difficult to use than
linux. For instance, linux compat isn't, as you
well know.
\_ freebsd harder than linux? holy shit, son! where
did you get *that* idea from? the free, online
freebsd handbook is clearly organised and has
updated to answers to all your major setup, config
and performance questions. linux is a mishmash of
google searching and prayer. -- old **nix admin
\_ Uh ... huh. Like why ports doesn't work?
\_ What is your opinion/experience with reiserfs?
\_ I have used ext3 extensively with no issues. I have
about 6 TB of storage with file sizes of several GBs.
What exactly is the problem?
\_ that's what we call 'getting lucky' in the IT world.
i hope you're keeping really good backups. of the
80 or so tb had on ext3, about 5tb spontaneously
corrupted with no advanced warning. unrecoverable.
my company no longer uses linux for storage systems
after the zillion crash and data loss event.
\- on performance issues you can look at the freenix
paper by bryant forrester hawks. i dont know if there
is an update to the paper [pls post if you know] --psb
\_ What if performance isn't an issue?
\- then use AssOS with AssFS
\_ ok another question, how easy is it to mirror
all partitions, including /, in freebsd with
software RAID ?
\- hmm, this is an interesting time to be asking.
if you are not invested in freebsd4 you might look
at GEOM. anyone using GEOM? also, in my experience
if you are not pretty familar with veritas, disk suite,
vinum etc you could be getting yourself into trouble
by booting off of it. after a machine has crashed is
not when you want to be reading man pages because
you used to do everything with GUIs etc. --psb
\_ heh, aint that the truth. make sure you've got a
bootable recovery cd and keep it up to date. this
applies to all boot disk raid systems.
\_ summary of above: ask a performance question regarding your
intended workload. ask a reliability question based on your
expected failure modes. if your most likely failures are
due to putting the system into random states w/ bad hardware,
bad power, or bad kernel modules: you need off-line backups.
we've been running a multi-TB filesystem on a dual processor
dell xeon server w/ software RAID0 striping for over a year
that gets completely beat on by local processes and NFS clients
who use it as volatile scratch space, yet we've never had a
problem. it lives in the relatively controlled environment
of a machine room. i believe we're using ext3 w/ relatively
stock redhat 9 software.
\_ ext3 on redhat, hehe, you've got another copy of anything
important, right? it took about year before i started seeing
problems, but maybe you wont see that since you're not keeping
data there long term.
\_ Some people have apparently had issues. At least two of
us on the motd have not. Your experience does not match mine.
Maybe your hardware sucks or there is some other variable. |
http://csua.com/feed/