All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: Rudy Zijlstra <rudy@grumpydevil.homelinux.org>
Cc: Reindl Harald <h.reindl@thelounge.net>,
	George Rapp <george.rapp@gmail.com>,
	Linux-RAID <linux-raid@vger.kernel.org>
Subject: Re: Recommended filesystem for RAID 6
Date: Wed, 12 Aug 2020 01:13:40 +0500	[thread overview]
Message-ID: <20200812011340.609e378f@natsu> (raw)
In-Reply-To: <e662446e-33e4-81fa-18ab-516fd140d51a@grumpydevil.homelinux.org>

On Tue, 11 Aug 2020 21:49:07 +0200
Rudy Zijlstra <rudy@grumpydevil.homelinux.org> wrote:

> >> no raid can replace backups anyways
> > All too often I've seen RAID being used as an implicit excuse to be lenient
> > about backups. Heck, I know from personal experience how enticing that can be.
> Is the backup not automatic? in that case it is no backup.

Sure it's automatic, by lenient I meant starting to exclude parts of their
data set from being backed up, deciding what is "important" and what is not,
and for the latter portion just hoping for the best because "it is RAID after
all, I can lose TWO drives, what could possibly go wrong". And then something
goes wrong, and it turns out even the data that was "not important" is actually
important enough to warrant scrambling for how to recover it, because
reobtaining it turns out to be costly / huge effort / not actually possible
even if they thought it will be.

> You have simply chosen a different set of mistakes to make. Considering 
> you need to update the "what is where" list regularly (is that 
> automated?)

Of course. In fact I'd suggest keeping similar lists no matter which storage
setup you run. One thing worse than losing data, is losing data *and* not
remembering what you had on there in the first place :)

-- 
With respect,
Roman

  reply	other threads:[~2020-08-11 20:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-11  4:42 Recommended filesystem for RAID 6 George Rapp
2020-08-11 15:06 ` Roy Sigurd Karlsbakk
2020-08-11 19:19   ` Michael Fritscher
2020-08-11 19:45     ` Wols Lists
2020-08-22  1:31       ` David C. Rankin
2020-08-22  7:25         ` Peter Grandi
2020-08-22  9:38           ` Wols Lists
2020-08-22 19:21             ` Chris Murphy
2020-08-22 19:04           ` Chris Murphy
2020-08-22 18:50       ` Chris Murphy
2020-08-22 19:54         ` Kai Stian Olstad
2020-08-22 23:50         ` antlists
2020-08-12 14:07     ` Nix
2020-08-11 15:22 ` antlists
2020-08-11 16:23 ` Roman Mamedov
2020-08-11 18:57   ` Reindl Harald
2020-08-11 19:33     ` Roman Mamedov
2020-08-11 19:49       ` Rudy Zijlstra
2020-08-11 20:13         ` Roman Mamedov [this message]
2020-08-11 20:17           ` Reindl Harald
2020-08-11 20:12       ` Reindl Harald
2020-08-11 22:14   ` Roy Sigurd Karlsbakk
2020-08-12 14:16   ` Nix
2020-08-12 14:41     ` Roman Mamedov
2020-08-12 20:44 ` Peter Grandi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200812011340.609e378f@natsu \
    --to=rm@romanrm.net \
    --cc=george.rapp@gmail.com \
    --cc=h.reindl@thelounge.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=rudy@grumpydevil.homelinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.