On 11/14/19 3:52 PM, Andrew Luke Nesbit wrote:
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
There was a thread a couple of months ago started by someone either pretty
ignorant or a troll.
The consensus answer: no more than any other OS, less than many.
On 11/14/19, U'll Be King of the Stars <ullbek...@andrewnesbit.org>
wrote:
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.
This is an excellent reason for implementing a system that includes not
only backups, but long term storage /archives/ too.
Andrew
One size definitely doesn't fit all.
Backup strategies depend on user's criteria, cost of design and
cost of doing the backups - administration & storage, etc.
In an ideal world every version of every file lasts forever.
Given real limitations, versioning filesystems can't and don't.
If your data are critical, invest in a dozen or more portable
USB drives. Cycle them off-site. Reread them (not too often)
to check for decay. If you have much $$$$ available, get a
modern tape system.
The backup system used over 50 years ago still suitable for many
circumstances looks something like this:
daily backups held for 1 month
weekly backups held for 6-12 months
monthly backups held indefinitely offsite.
Hold times vary according to circumstances.
The backup(8) program can assist this by storing deltas so that
more frequent backups only contain deltas from the previous
less frequent backup.
The compromise between backup storage requirements and granularity
of recovery points can be mitigated. The way to do it depends on
the type and structure of the data:
Some data are really transient and can be left out.
Source code control systems (or whatever the name is this week)
are a good way for intermittent backups to capture a good history
of whatever data is around if it's text.
DBs often have their own built-in backup mechanisms.
Binary files can be regenerated if the source *and* environment
are backed up.
Etc.
YMMV and MEGO
geoff steckel
been there, mounted the wrong tape... what write protect ring?
