28 Mar
2018
28 Mar
'18
10:09 a.m.
-------- Original message --------
From: Chuck Guzis via cctalk <cctalk at classiccmp.org>
Date: 3/28/18 10:02 AM (GMT-08:00)
To: Paul Koning via cctalk <cctalk at classiccmp.org>
Subject: Re: RAID? Was: PATA hard disks, anyone?
I know of no RAID setup that can save me >from
stupid.
Chuck,
As we say in my day job "there is no curing stupid" ;)
-Ali
28 Mar
28 Mar
10:17 a.m.
I know of no RAID setup that can save me >from
stupid.
I use rsync. I manually rsync the working disks to the backup disks every
week or two. Working disks have the shares to other hosts. If something
happens to that data, deleted by accident or encrypted by malware. Meh.
Hardware like netapp and maybe filesystems in open source have those
awesome snapshot systems with there is directory tree that has past time
version of data. A directory of 15 minutes ago, one of 6 hours ago, etc
is what we had setup at a prior gig.
--
: Ethan O'Toole
10:51 a.m.
On 28 March 2018 at 18:17, Ethan via cctalk <cctalk at classiccmp.org> wrote:
I know of no RAID setup that can save me >from
stupid.
I use rsync. I manually rsync the working disks to the backup disks every
week or two. Working disks have the shares to other hosts. If something
happens to that data, deleted by accident or encrypted by malware. Meh.
Hardware like netapp and maybe filesystems in open source have those
awesome snapshot systems with there is directory tree that has past time
version of data. A directory of 15 minutes ago, one of 6 hours ago, etc is
what we had setup at a prior gig.
Possible helpful note on the off chance anyone wasn't already aware
(apologies for those who already know)
A step up from rsync can be dirvish - it uses rsync, but before each backup
it creates a hardlink tree of the previous backup, then rsyncs over it. The
net effect is you only pay the block cost of one copy of unchanged files,
plus an inode per copy. Can be very handy :)
David
10:55 a.m.
On 03/28/2018 11:51 AM, David Brownlee via cctalk wrote:
A step up from rsync can be dirvish - it uses rsync,
but before each
backup it creates a hardlink tree of the previous backup, then rsyncs
over it. The net effect is you only pay the block cost of one copy of
unchanged files, plus an inode per copy. Can be very handy
I've used something like that with great success. - This is commonly
known as "Single Instance Store".
The only down side is that there is a single copy of the file, and if
something happens to it, the entire backup set is impacted.
This is easy to get around by periodically creating a new set backup set
that future days are hard linked against. (Play with the numbers to
match your preference.)
--
Grant. . . .
unix || die
10:57 a.m.
On 03/28/2018 10:17 AM, Ethan via cctalk wrote:
I don't even use rsync. I have a duplicate system just off to my left
installed with the same software. Every time I reach a "good enough"
point, I simply do a "tar czf ..." on my work area and ftp the resulting
code to the other machine. i.e., it's basically a "rolling" backup.
The second system is always one set of system updates behind the current
one, which provides some insurance.
Should disaster strike, I need only use my other system with the latest
backup and I'm back up and running in a matter minutes.
But that still doesn't save me from stupid. A second cup of coffee
could do that...
--Chuck
I know of no
RAID setup that can save me >from stupid.
I use rsync. I manually rsync the working disks to the backup disks
every week or two. Working disks have the shares to other hosts. If
something happens to that data, deleted by accident or encrypted by
malware. Meh. 
10:58 a.m.
On 2018-03-28 1:17 PM, Ethan via cctalk wrote:
Yeah was wondering when the discussion might bring up ZFS...
I know of no
RAID setup that can save me >from stupid.
I use rsync. I manually rsync the working disks to the backup disks
every week or two. Working disks have the shares to other hosts. If
something happens to that data, deleted by accident or encrypted by
malware. Meh.
Hardware like netapp and maybe filesystems in open source have those
awesome snapshot systems with there is directory tree that has past time
version of data. A directory of 15 minutes ago, one of 6 hours ago, etc
is what we had setup at a prior gig.
--
: Ethan O'Toole
29 Mar
29 Mar
3:48 p.m.
On Wed, Mar 28, 2018 at 01:17:08PM -0400, Ethan via cctalk wrote:
At a prior job, I replaced the standard NFS+Samba filesharing mess (with
the regular "I need you to twiddle permissions" fun) with an AFS server.
Native clients for both Linux and Windows2000. With access to the ACLs
built right into the native interfaces, so that regular call went away.
Also, AFS is built around volumes (think "virtual disks") and you have
the concept of a r/w volume with (potentially) a pile of r/o volumes
snapshotted from it. So one thing I did was that every (r/w) volume
had a directory .backup in its root where there was mounted a r/o
volume snapshooted from the r/w volume around midnight every day.
That killed about 95% of the "I accidently deleted $FILE, can you please
dig it out of the backup" calls.
Plus, it made backups darn easy.
Last I heard, after I left that place, they setup a second AFS server.
Oh, AFS as in: the Andrew File System
Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
I know of no
RAID setup that can save me >from stupid.
I use rsync. I manually rsync the working disks to the backup disks every
week or two. Working disks have the shares to other hosts. If something
happens to that data, deleted by accident or encrypted by malware. Meh.
Hardware like netapp and maybe filesystems in open source have those awesome
snapshot systems with there is directory tree that has past time version of
data. A directory of 15 minutes ago, one of 6 hours ago, etc is what we had
setup at a prior gig.
4:45 p.m.
On 03/29/2018 03:48 PM, Alexander Schreiber via cctalk wrote:
Also, AFS is built around volumes (think "virtual
disks") and you have
the concept of a r/w volume with (potentially) a pile of r/o volumes
snapshotted from it. So one thing I did was that every (r/w) volume
had a directory .backup in its root where there was mounted a r/o
volume snapshooted from the r/w volume around midnight every day.
CDC 6000 SCOPE 3.3 and later implemented permanent files with file
"cycles". That is, earlier versions of a file were kept around.
The approach was a little different. You initially started a job or
session with no files, but for INPUT (wherever it came from) OUTPUT
(display or print output) and optionally PUNCH (obvious meaning). A
dayfile was also maintained, but the individual user could only add to
it, not otherwise manipulate it.
To do real work on an ongoing project involved ATTACH-ing a permanent
file that had been CATALOG-ed. Paswords (up to 3) and permissions
needed to be specified to ATTACH a file. This, IIRC, created a local
copy of the file. If you mistakenly deleted the local copy, you still
had the permanent copy. If you saved the local copy after modifying it,
it was saved as a new cycle.
A user could PURGE old permanent file cycles.
The beauty of this was that a user had access to the files that were
needed for a session. A user could, of course, create as many local
files as desired, but these were all disposed of at the end of the
job/session, so there wasn't a lot of garbage floating around in the system.
A side benefit was that permanent files could be archived to tape, so
when an ATTACH was issued for an archived file, the job was suspended
until the relevant tape was located and read.
I suspect that modern users would consider the system to be too
restrictive for today's tastes, but it was fine back then.
--Chuck
28 Mar
28 Mar
10:17 a.m.
On 2018-03-28 2:09 PM, Ali via cctalk wrote:
-------- Original message --------
From: Chuck Guzis via cctalk <cctalk at classiccmp.org>
Date: 3/28/18 10:02 AM (GMT-08:00)
To: Paul Koning via cctalk <cctalk at classiccmp.org>
Subject: Re: RAID? Was: PATA hard disks, anyone?
You mean something like someone who writes a script that does blind cd
to the directory and then proceeds to delete the contents? Customer's
system started crashing at noon every day after they did an OS update
that eliminated the target directory.? The script was kicked of by cron
and the cd would fail and since they where not checking if it succeeded
or if they ended up in the right place the script proceed to delete
everything from its current directory, which unfortunately was where all
the libraries live... oopps...
Paul.
I know of no RAID setup that can save me >from
stupid.
Chuck,
As we say in my day job "there is no curing stupid" ;)
-Ali
10:53 a.m.
On 03/28/2018 11:17 AM, Paul Berger via cctalk wrote:
You mean something like someone who writes a script
that does blind cd
to the directory and then proceeds to delete the contents?
This is one of the primary reasons that I prefer to see the full path
specified on the rm command.
--
Grant. . . .
unix || die
2460
days inactive
2461
days old
9 comments
8 participants
participants (8)
-
abs＠absd.org -
als＠thangorodrim.ch -
cclist＠sydex.com -
cctalk＠gtaylor.tnetconsulting.net -
cctalk＠ibm51xx.net -
ethan＠757.org -
phb.hfx＠gmail.com -
toby＠telegraphics.com.au