[Info-vax] File Systems

[Stephen Hoffman]

On 2015-03-06 03:22:14 +0000, JF Mezei said:

> On 15-03-05 14:46, Stephen Hoffman wrote:
> 
>> Or consistent, continuous, online backups,
> 
> 
> How about using volume shadowing where one member is a special member
> with differeent low level driver and its role is just to receive all
> writes and update a "backup save set" in real time ?

This can be viewed as is a way to push the equivalent of a BACKUP 
/IGNORE=INTERLOCK "backup" down closer to the storage controller level, 
or a way to push a (bad) storage-level backup up into HBVS.

Applications almost invariably use more than one disk, so you'll have 
to capture and coordinate the I/O across all of the storage devices the 
application(s) use.  Consistently timestamping or sequence numbers for 
blocks across multiple streams across multiple controllers which may be 
on multiple hosts in multiple timezones with multiple DST changes over 
time is going to be an interesting side-project, too — database indexes 
can involve some of these trade-offs, but I digress.  Then you have to 
figure out how to do manage parallel backups, and how to restart 
operations when the connections fail or the backup devices are offline 
for a transient operation or are replaced — these are some of the 
details that shadowing implements with minicopy and minimerge and full 
copies, of course — though these are all at a single point in time; at 
now.  Then you have to figure out how to do those same minicopy and 
minimerge and full copy operations for your block streams and with 
whatever data structures you're feeding the blocks into, across 
multiple cluster members, coordinating your backups with the usual HBVS 
activities involving a distributed pool of disks that may not all be 
present and working and accepting and rejecting I/O requests and 
revectoring or kicking out volumes — and to do this over time; to have 
multiple backups over time, as files are added and deleted and modified 
over the course of a day or a year.

Then you have to figure out how to restore the data back out of your 
ginormous pool of blocks — the users will be looking for files, and you 
have ginormous data structures of the timestamped historical block 
addresses and block contents.

Then you have to figure out how to cull specific data, or the oldest 
data, from your archives.  Not everybody will want or can afford the 
hardware for an ever-expanding pool of backup data, after all.

Then there's data compression, data encryption (which gets slightly 
gnarly as folks can want to change the keys over time, and then there's 
the general and usual "fun" with encryption such as ECB mode 
<http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation> and key 
management), and probably also figuring out how to ignore zeroed blocks 
and whether the host provides TRIM 
<http://en.wikipedia.org/wiki/Trim_(computing)>.

Like the storage engineers that have tried similar schemes, you also 
don't know where the application-determined points of consistency are, 
within the streams of blocks that are arriving at HBVS in this case or 
at the controller — so unless every application uses careful 
write-ordering and either no write caches or careful write cache 
management, you're likely to have one or more incomplete transactions 
depending on how many applications and devices are active and writing 
when the connection was broken, or at the point in time that you're 
trying to restore to.

Getting wads of blocks copied somewhere is fairly easy, in the scheme 
of storage.   The storage controller backup schemes have been doing 
that for eons, after all.   Getting application data that's manageable 
and consistent and easily restorable?   That's a much tougher problem, 
particularly when there's no insight back into the host I/O activity.  
For various environments, getting a consistent backup requires 
application assistance.  This is the RMU /BACKUP utility or other 
similar database-level tools and the associated processing to determine 
a point where the database data is consistent.

Whether a database or a backup, consistency can be a tough problem, and 
there are almost always trade-offs involved.   Various storage 
controllers have been generating hard-to-restore "backups" at least as 
far back as the 1980s, and probably before.  As have the folks using 
BACKUP /IGNORE=INTERLOCK, for that matter.  For an overview of the 
general approaches involved here, see ACID and BASE and related.  
<http://en.wikipedia.org/wiki/ACID> 
<http://en.wikipedia.org/wiki/Eventual_consistency> 
<http://en.wikipedia.org/wiki/CAP_theorem>  
<http://en.wikipedia.org/wiki/Database_transaction> Etc.





-- 
Pure Personal Opinion | HoffmanLabs LLC