On 8/1/23 2:49 AM, Colin Paice wrote:
Your Copy on Write - may be what I know as dual write - where you
write to different volumes - usually on different dasd subsystems,
so if you lose one dasd subsystem - the data is available on another.
Nope. "Copy on Write" is explicitly what you were previously describing
where in multiple references to the data had the same singular copy of
the data in the back-end and and things are copied only when one of the
references to the data changes the data. As long as COW instances use
the exact same data, as in base OS data sets from the same OS version,
then there's only the single instance, independent of how many
references to it there are.
I see writing to multiple drives in parallel -- from an OS / software
level -- referred to as software RAID / mirroring.
COW and RAID (mirroring) are different things meant to serve different
purposes.
You can have synchronous write - used in same "site" and async -
where the remote end is miles away. This is used for media failure.
Yes. Emphasis on /media/ failure. This does nothing for /data/
failure, e.g. corruption / malicious activity.
Traditional offline backups address both /media/ failure and /data/ failure.
Note. This is not a backup. If you delete the dataset, both copies
will be deleted.
needMOREcoffee We seem to be thinking very similar things but typing at
different times.
I was talking about what I think is called snapshot. It is used like
1- Issue Snapshot copy (of your database) - this takes a couple of
seconds or less.
I usually see snapshots created a couple of different ways:
1) The older way was to pause things and take an actual copy. This was
slower and took quite a while O(minutes ~> hours).
2) The newer way seems to be some sort of -- what I would call -- COW
system where changes to parts of the storage are written to a new
location and access to the primary / live interface reflect the new
data. Conversely the snapshot interface reflects the old data from the
point in time the snapshot was made. This is faster and takes much less
time O(seconds).
The gory details of how it's done are implementation specific.
2- Backup this copy - it may take a couple of hours to read from the
DASD subsystem, and write to perhaps Virtual Tape.
Agreed.
3- The original data set continues to be updated, whereas the copy
does not change, so you have point of time consistency
Agreed.
4- You can restore to the point of time, and for products like DB2
and MQ, read the logs and reapply all of the updates.
I think I agree though I will say that depending on how the snapshot was
taken and if the higher level applications are aware of the snapshot and
quiesced in support of the snapshot may make the difference between a
"crash consistent" snapshot / copy and a "suspend consistent" snapshot.
This type of consistency and how the applications roll forward here from
gets interesting and tricky.
But, even a crash consistency snapshot is almost always more current and
easier to recover than a cold backup from hours / days ago. Or at least
looses less data / is more fresh / less effort to bring back current.
Grant. . . .
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
