On Wed, 06 Feb 2013 09:41:39 -0500
Derek Atkins wrote:
> Sounds like you want RAID1..
NO.
NO.
NO.
A THOUSAND TIMES, NO!
RAID provides no data integrity. None. Zilch. Zero. Nada.
Given two mirrored disks A and B. If you accidentally run a recursive
delete like Rich did then your data is gone
"Rich Braun" writes:
> Edward Ned Harvey (blu) stated:
>>> Well, ext4 performs so much better. If the only risk is the lack of
>>> availability of undelete tools, then I say, the better solution is to use
>>> ext4 and backups.
>
> Jack echoed:
>> Ed, that seems like a better approach for most us
On Tue, 5 Feb 2013 11:57:02 -0500
Rich Pieri wrote:
> have 3Gbps or faster disks. Then you get the snapshot mechanism which
> can help protect against accidental erasures.
Which I just did. I had taken BitBleach for a test drive and started it
doing a deep clean which cleans up Emacs backup file
On Tue, 5 Feb 2013 08:37:34 -0800
"Rich Braun" wrote:
> I think I'm out of options, and have lost about 400GB that hadn't yet
> been backed up. But I'll keep that terabyte volume around just in
> case it's ever retrievable. Meanwhile I mean what I say about not
> using ext4 for this use case an
Tom suggested:
> You tried 'foremost' ?
Foremost found only the .png files, and didn't find any .mpg files. I may be
able to retry it in some other way, but I'd need more tech info about it.
> These tools are designed to sift through unallocated space on a
> drive and recognize common file struc
Edward Ned Harvey (blu) stated:
>> Well, ext4 performs so much better. If the only risk is the lack of
>> availability of undelete tools, then I say, the better solution is to use
>> ext4 and backups.
Jack echoed:
> Ed, that seems like a better approach for most uses.
But think about my use case
On Tue, 5 Feb 2013 13:41:10 +
"Edward Ned Harvey (blu)" wrote:
> Well, ext4 performs so much better. If the only risk is the lack of
> availability of undelete tools, then I say, the better solution is to
> use ext4 and backups.
IME, ext4 does not perform "so much better" than ext3. Sometim
Ed, that seems like a better approach for most uses.
I was doing a backup system for an employer, and we had a 'large'
linux server with enough memory, so I used EXT2 for the file system,
because 3 and 4 even more so used more disk space for their cache to
increase performance. I liked having the
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Rich Braun
>
> It's starting to look to me like the bottom line is this:
>
> DO *NOT* USE EXT4!
>
> There are a handful of well-documented utilities available for recovering ext
On 02/05/2013 02:27 AM, Tom Metro wrote:
Rich Braun wrote:
There are a handful of well-documented utilities available for recovering ext3
volumes, and pretty much nothing for ext4. The ones that claim support for
ext4 give no meaningful debugging output, and rely solely on contents of a
journal
Rich Braun wrote:
> There are a handful of well-documented utilities available for recovering ext3
> volumes, and pretty much nothing for ext4. The ones that claim support for
> ext4 give no meaningful debugging output, and rely solely on contents of a
> journal that's apparently gone.
You tried
It's starting to look to me like the bottom line is this:
DO *NOT* USE EXT4!
There are a handful of well-documented utilities available for recovering ext3
volumes, and pretty much nothing for ext4. The ones that claim support for
ext4 give no meaningful debugging output, and rely solely on co
12 matches
Mail list logo
