<div dir="ltr"><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif">Thanks for the kind words, Rick.</font></div><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif">After hitting send and seeing your addition, a couple things came to mind that are important to point out.</font></div><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_extra"><div class="gmail_quote"><font face="arial, helvetica, sans-serif">On Wed, Feb 1, 2017 at 5:22 PM, Rick Troth <span dir="ltr"><<a href="mailto:rmt@casita.net" target="_blank">rmt@casita.net</a>></span> wrote:<br></font><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="m_1160137094439927824moz-cite-prefix"><font face="arial, helvetica, sans-serif"><br>
<u>I must recommend RSYNC</u> as a first course for proving things
or for in-a-pinch replication needs. It's like option C since
RSYNC is just an application. One feature of RSYNC is that it can
avoid sending bits which match what the receiver already has. I
also like that it can be told to not step on a newer copy (if
source and target may each have newer versions of some files). <br>
<br></font></div></div></blockquote><div><font face="arial, helvetica, sans-serif"><br></font></div><div><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif">RSYNC is great. It's been around for years, it's well-documented, and super reliable. But the only downside of RSYNC (or on Windows, for those that care, RSYNC's distant cousin, ROBOCOPY) is you have to kick it off each time you want to replicate. One could create a wrapper that 1) checks if rsync is already running (exit if so), then 2) starts the rsync process to do the replication. Bi-Di replication works too, but you'll have to go out of your way if you ever want to delete a file (which you also mentioned). RSYNC is tried and proven, and I've seen more than one organization use a script ran by a cron job to replicate their filesystems across a distance. Spacing a timed RSYNC out at like 15 minute intervals would expose you to some data loss, but at the same time, provide a little bit of a safety net in the case of an accidental deletion. (unless you delete the file right as the script is kicking off, and then you're hosed)</font></div><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif"><br></font></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_1160137094439927824moz-cite-prefix"><font face="arial, helvetica, sans-serif"><br>
I've <u>also seen option A used</u> in rigorous off-site and
heavily exercised D/R. (We're talking greater than 300 miles.)
Options A and C both allow for any filesystems you might need or
choose. (Not that there's anything wrong with option B, FS based
solutions.) Option A often requires that you go deep with a
specific storage vendor or service. <br>
<br></font></div></div></blockquote><div><font face="arial, helvetica, sans-serif"><br></font></div><div><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif">There are many ways to deploy "enterprise storage" -- DR is the primary use case for this, rather than HA (high availability), and to make it really bulletproof, one would employ a 3-site configuration, with a primary, a close-enough for synchronous replica, and then a farther-away asynchronous replica (near-near-far as I refer to it). This gives you a nearby synchronous mirror of the data, and meets most organization's requirement that the DR copy be geographically disparate. This also requires you commit heavily to a storage vendor and have matching kit in all locations. Which, of course, depends on how much of an investment the company or organization is willing to make. (read: how much revenue is exposed if the data weren't recoverable in the case of an outage) RPO and RTO factor heavily into what kind of design is needed. Near-near-far is pretty much the only guaranteed way to get zero-RPO that I know of. If someone comes to the meeting and says "I can never lose data, ever" this is the prescription for that requirement. If RPO is greater than 0 but still measured in minutes? One could choose a Near-Far 2-site configuration, replicating asynchronously and probably still meet that requirement.</font></div><font face="arial, helvetica, sans-serif"><br></font></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_1160137094439927824moz-cite-prefix"><font face="arial, helvetica, sans-serif">The option A work that I was involved in was for a former
employer. Most of the exercise was truly outstanding, excellent
work. But procedures historically included <u>applying updates
via tape</u> (after snap-shot of the storage across the 300-mile
link). I am just not a fan of tape anymore for a variety of
reasons. Was annoyed that the D/R exercise would consistently burn
many hours for all the tape work, but was not the decision maker.
<br>
<br></font></div></div></blockquote><div><font face="arial, helvetica, sans-serif"><br></font></div><div><div class="gmail_default" style="color:rgb(51,0,51)"><font face="arial, helvetica, sans-serif">Good point here about tape in this context - offsite replication is NEVER a substitute for a rigorous backup routine. If someone borks a file, or worse, a database in the primary site and that data is being replicated, that far copy is equally useless. Don't let anyone ever talk you out of backups for the sake of replication and snapshots and all the features you have available these days. (Same goes for RAID -- RAID is not backup, either.) You may have some ability to undo a database change, by halting the database, rolling back log entries to the point of the database being un-borked, but that's both time-consuming and not always reliable. </font></div><div class="gmail_default" style="color:rgb(51,0,51)"><br></div><div class="gmail_default" style="color:rgb(51,0,51)"><br></div><div class="gmail_default" style="color:rgb(51,0,51)"><span style="font-family:arial,helvetica,sans-serif;color:rgb(34,34,34)">Best,</span></div><div class="gmail_default" style="color:rgb(51,0,51)"><span style="font-family:arial,helvetica,sans-serif;color:rgb(34,34,34)">Angelo</span><br></div><div class="gmail_default" style="color:rgb(51,0,51)"><span style="color:rgb(34,34,34)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div class="gmail_default" style="color:rgb(51,0,51)"><span style="color:rgb(34,34,34)"><font face="arial, helvetica, sans-serif"> </font></span></div></div></div></div></div>