<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body smarttemplateinserted="true">
    <div id="smartTemplate4-quoteHeader">
      <div style="font-size:10.0pt;font-family:Verdana,Arial">> There
        may be an argument that could be made for 2 backup stratagies<br>
        <br>
        That's the point. In the context of SME environments (Small and
        Medium-sized Enterprises, i.e. from 5 to 50 employees normally,
        up to 250 in some countries) that we were talking about, a
        replication is an overkill, IMO. But for large enterprises like
        MNCs, large universities, public mail providers (Fastmail) of
        course multiple masters and backups via replication is the way
        to go. For large deployments there are good backup solutions in
        Cyrus, but for the small businesses admins I don't know any to
        recommend.<br>
        <br>
        > If the mailboxes are on something like EXT4 you can do an
        LVM snapshot bacause of the built in auto checkpointing and for
        something like xfs there is freeze.<br>
        <br>
        Yepp, this is the idea. But the data on disk should be in a
        consistent state. Something like "FLUSH TABLES WITH READ LOCK"
        is what is needed actually, i.e. to consistently write to disk
        the data from the current instance and lock.<br>
        <br>
        > The trouble is that read operations can alter a files state
        so it may not be just a simple matter of a write lock.<br>
        <br>
        If you mean things like SEEN state that are changed when the
        user reads something, the implementation v1 could block it, v2
        could allow it by queuing in memory such state-change pending
        operations. Anyway these are just implementation details that
        don't change the general logic and, taking into account the
        supposed duration of the lock, IMO don't even matter much. The
        significant work that blocks this feature is the global lock
        across the entire Cyrus. Once it's implemented, it would be much
        easier to introduced specific improvements here and there.<br>
        <br>
        > Cyrus has multiple databases that would also need to be
        frozen and flushed before the snapshot is taken.<br>
        > If you spread your mailstorage and metadata storage over
        multiple file systems trying to co-ordinate snapshots becomes
        more complex.<br>
        <br>
        Sure, Cyrus would have to lock all the databases and where to
        store them would be up to the admin. Actually, fs snapshots is
        just the most obvious use-case. There could be others... up to
        the admin to decide.<br>
        <br>
      </div>
      <div style="border:none;border-top:solid #B5C4DF
        1.0pt;padding:3.0pt 0cm 0cm
0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
        Alvin Starr<br>
        <b>Sent:</b> Thursday, May 10, 2018 23:55<br>
        <b>To:</b> Info-cyrus<br>
        <b>Subject:</b> Re: Backup methods<br>
      </div>
      <br>
    </div>
    <span type="cite"
      cite="mid:9aad5a1c-d98a-d6c1-6be0-f2b63975a510@netvel.net"
      style="display: block; word-break: break-all; margin: 7px 0 0 0;
      padding: 0; line-height:0"></span>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    On 05/10/2018 06:29 PM, Anatoli wrote:<br>
    <blockquote type="cite"
      cite="mid:e9e1f812-7155-727d-a588-df6359183c1d@anatoli.ws">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div id="smartTemplate4-quoteHeader">
        <div style="font-size:10.0pt;font-family:Verdana,Arial">Actually,
          mysqldump performs a lock on the records it's dumping. If its
          for a MyISAM db, the entire table is locked. If it's for
          InnoDB and similar, an internal snapshot is created and only
          the records the dump is reading are unavailable for writing.<br>
        </div>
      </div>
    </blockquote>
    Mysql provides table consistency by locking but that is only table
    consistency.<br>
    Multiple updates across multiple tables could easily result in an
    inconsistent database even though the tables are individually
    consistent.<br>
    With some tables that take hours to dump locking the tables is
    problematic.<br>
    This is why some people use LVM snapshots combined with "FLUSH
    TABLES WITH READ LOCK".<br>
    <blockquote type="cite"
      cite="mid:e9e1f812-7155-727d-a588-df6359183c1d@anatoli.ws">
      <div id="smartTemplate4-quoteHeader">
        <div style="font-size:10.0pt;font-family:Verdana,Arial"> <br>
          Cyrus could also implement a per-user lock, but in reality it
          doesn't need that complex syncro mechanisms, a simple global
          write lock would be enough (reading would not be affected, son
          only I, not I/O, and not to stop it but just to suspend).
          After all, the *write* lock would last only a second or so,
          the fs snapshots are almost instantaneous. If you can't
          tolerate a 1 second delay for writing in Cyrus, you are
          probably not a SME.<br>
        </div>
      </div>
    </blockquote>
    The trouble is that read operations can alter a files state so it
    may not be just a simple matter of a write lock.<br>
    If the mailboxes are on something like EXT4 you can do an LVM
    snapshot bacause of the built in auto checkpointing and for
    something like xfs there is freeze.<br>
    <br>
    Cyrus has multiple databases that would also need to be frozen and
    flushed before the snapshot is taken.<br>
    If you spread your mailstorage and metadata storage over multiple
    file systems trying to co-ordinate snapshots becomes more complex.<br>
    <br>
    <blockquote type="cite"
      cite="mid:e9e1f812-7155-727d-a588-df6359183c1d@anatoli.ws">
      <div id="smartTemplate4-quoteHeader">
        <div style="font-size:10.0pt;font-family:Verdana,Arial"> <br>
          And you don't need to hold the data to transfer it. You can
          dump it directly to a nfs share or pass it as stdout to ssh: <font
            face="Courier New">mysqldump | xz -9 | ssh remote_server
            "cat > /bkp/</font><font face="Courier New"><font
              face="Courier New">`date +%y%m%d_%H%M`.sql.xz</font>"</font>.
          With a couple of pipes more you can encrypt the data on the
          fly so it's secure to store it in a cheap VPS overseas... or
          you could upload it to dropbox.<br>
        </div>
      </div>
    </blockquote>
    <br>
    There may be an argument that could be made for 2 backup stratagies.<br>
    1) where the mailstoreage and metadata can exist on a single volume
    and flushing the various databases is a short duration event. Then
    an LVM snapshot could be used <br>
    2) for distribted large scale mail systems where only an online live
    backup system can be used.<br>
    <br>
    Backup for 100 users has different requirements than backup for
    100000 users so why not support a few different backup strategies.<br>
    <br>
    <blockquote type="cite"
      cite="mid:e9e1f812-7155-727d-a588-df6359183c1d@anatoli.ws">
      <div id="smartTemplate4-quoteHeader">
        <div style="font-size:10.0pt;font-family:Verdana,Arial"> <br>
        </div>
        <div style="border:none;border-top:solid #B5C4DF
          1.0pt;padding:3.0pt 0cm 0cm
0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
          Jason L Tibbitts Iii<br>
          <b>Sent:</b> Thursday, May 10, 2018 18:41<br>
          <b>To:</b> Anatoli<br>
          <b>Cc:</b> Info-cyrus<br>
          <b>Subject:</b> Re: Backup methods<br>
        </div>
        <br>
      </div>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <blockquote type="cite">
              <blockquote type="cite">
                <pre wrap="">"A" == Anatoli  <a class="moz-txt-link-rfc2396E" href="mailto:me@anatoli.ws" moz-do-not-send="true"><me@anatoli.ws></a> writes:
</pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <pre wrap="">A> What about mysqldump > dump.sql, then mysql < dump.sql? Also a wrong
A> way and didn't have to be implemented?

No, that's exactly my point.  Thanks for making it for me!  The analog
to the way you indicated that you would like it to work would be having
the mysql server stop IO so that you can take a filesystem snapshot
while the database is in a consistent state.  But instead, the database
(like cyrus) implements a backup method which you can use to extract the
data.  And it also requires disk space to hold the backup until you can
transfer it to your backup medium.

 - J<


</pre>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">----
Cyrus Home Page: <a class="moz-txt-link-freetext" href="http://www.cyrusimap.org/" moz-do-not-send="true">http://www.cyrusimap.org/</a>
List Archives/Info: <a class="moz-txt-link-freetext" href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/" moz-do-not-send="true">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a>
To Unsubscribe:
<a class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus" moz-do-not-send="true">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Alvin Starr                   ||   land:  (905)513-7688
Netvel Inc.                   ||   Cell:  (416)806-0133
<a class="moz-txt-link-abbreviated" href="mailto:alvin@netvel.net" moz-do-not-send="true">alvin@netvel.net</a>              ||

</pre>
    <br>
    <fieldset class="mimeAttachmentHeader"></fieldset>
    <br>
    <pre wrap="">----
Cyrus Home Page: <a class="moz-txt-link-freetext" href="http://www.cyrusimap.org/">http://www.cyrusimap.org/</a>
List Archives/Info: <a class="moz-txt-link-freetext" href="http://lists.andrew.cmu.edu/pipermail/info-cyrus/">http://lists.andrew.cmu.edu/pipermail/info-cyrus/</a>
To Unsubscribe:
<a class="moz-txt-link-freetext" href="https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus">https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus</a></pre>
    <br>
  </body>
</html>