Hi Dave,

On 15/11/2019 07:44, Raymond, David wrote:
I hadn't heard about file corruption on OpenBSD.  It would be good to
get to the bottom of this if it occurred.

I was surprised when I read mention of it too, without any real claim or detailed analysis to back it up. This is why I added my disclaimer about "correcting me if I'm wrong because I don't want to spread incorrect information".

The reason why I brought it up on a public mailing list was to find out if anybody else has heard any inkling _at all_ regarding this, even a skerrick of a mention.

I have a feeling I may have even heard about it on this list but I'm not sure. If somebody out there genuinely suspects that this happened then it would be good to know so we can clear it up.

Kind regards,

Andrew

On 11/14/19, U'll Be King of the Stars <ullbek...@andrewnesbit.org> wrote:
On 15/11/2019 04:45, Raymond, David wrote:
I have done similar things on Linux for years and am now doing them on
OpenBSD.  Sounds like what you want to do can be done with a simple
rsync script.  OpenBSD ffs (ufs) should be stable, it has been around
for decades in various incarnations.  I have never noticed bit rot in
this system, though I imagine it could happen if a disk is gradually
going bad.

Please correct me if I'm wrong because I don't want to spread incorrect
information.

A couple of months ago I read a couple of reports of filesystem
corruption on OpenBSD.  I didn't have time to investigate deeply and I
don't know if these issues were even real.  Even if they were real I
don't know if the problem was due to user error or a defect in the OS.

Does anybody know anything about this?

That's why multiple backups help.

Agreed.  See below.

You might want to set
up a raid5 backup, as this detects parity errors.  More complicated
though.

This is exactly the kind of reason that hybrid volume management systems
+ filesystems such as Btrfs and ZFS have become popular.

I do not know anything about OpenBSD's LVM.

One weakness in such as system (ask me how I know!) is that
if the NAS goes gradually bad, the errors will propagate to the
backup.  Using rsync without the --delete option most of the time
alleviates this somewhat.  Only run with --delete when the backup
starts getting full and you are confident that your NAS drive is ok.

This is an excellent reason for implementing a system that includes not
only backups, but long term storage /archives/ too.

Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9




--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Reply via email to