As Michael states, you can use ML backup or EBS Snapshots in conjunction with Flash Backup mode to move data to S3. You can run the ML backup to S3 directly or to any other IO device. We do not support direct writes to Glacier - lifecycle policies is the recommended path from Amazon anyway. Once data is in S3 - either a volume snapshot or an ML backup - use S3 lifecycle policies to migrate from S3 to Glacier. Do not use any direct file copy routines for backup of a MarkLogic database (or,for that matter, most other databases ).
Aaron Rosenbaum Senior Director, Product Strategy 999 Skyway Road, San Carlos, CA 94070 [email protected] cell: 650-703-7517 desk: 650-287-2573 <http://www.twitter.com/arosenbaum> <http://www.linkedin.com/in/aaronrosenbaum> On 1/13/14, 12:00 PM, "[email protected]" <[email protected]> wrote: >Send General mailing list submissions to > [email protected] > >To subscribe or unsubscribe via the World Wide Web, visit > http://developer.marklogic.com/mailman/listinfo/general >or, via email, send a message with subject or body 'help' to > [email protected] > >You can reach the person managing the list at > [email protected] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of General digest..." > > >Today's Topics: > > 1. Backing up MarkLogic (Dunlap, Zachariah) > 2. Re: Backing up MarkLogic (Geert Josten) > 3. Re: Backing up MarkLogic (Michael Blakeley) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Mon, 13 Jan 2014 15:13:16 +0000 >From: "Dunlap, Zachariah" <[email protected]> >Subject: [MarkLogic Dev General] Backing up MarkLogic >To: "[email protected]" > <[email protected]> >Message-ID: > <[email protected]> >Content-Type: text/plain; charset="us-ascii" > >We are considering simply backing up the "\Program Files\MarkLogic" >folder on each machine in our cluster using Amazon Glacier instead of >making backups using the "Backup & Restore" feature. > >We'd love to get some feedback from others to try and helps us weigh the >pros and cons of simply backing up the data on the disk, vs. using >MarkLogic's backup feature. > >Thank you all in advance for your thoughts. > >-Zach > > > >The information contained in this communication is intended for the use >of the designated recipients named above. If the reader of this >communication is not the intended recipient, you are hereby notified >that you have received this communication in error, and that any review, >dissemination, distribution or copying of this communication is strictly >prohibited. If you have received this communication in error, please >notify The Associated Press immediately by telephone at +1-212-621-1898 >and delete this email. Thank you. >[IP_US_DISC] > >msk dccc60c6d2c3a6438f0cf467d9a4938 >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >http://developer.marklogic.com/pipermail/general/attachments/20140113/9bbc >f2a5/attachment-0001.html > >------------------------------ > >Message: 2 >Date: Mon, 13 Jan 2014 19:01:44 +0100 >From: Geert Josten <[email protected]> >Subject: Re: [MarkLogic Dev General] Backing up MarkLogic >To: MarkLogic Developer Discussion <[email protected]> >Message-ID: <[email protected]> >Content-Type: text/plain; charset="windows-1252" > >Hi Zach, > > > >That is what the Forest status ?flash-backup? is intended for. I thought >it >slowed down things a bit, but from the looks of the Help in the Admin >interface, it is really meant for very short interruptions: > > > >flash-backup puts the forest in read-only mode without throwing exceptions >on insert, update, or delete transactions, allowing the transactions to >retry. > > > >You might want to automate/script switching the forest statuses back and >forth.. > > > >Cheers, > >Geert > > > >*Van:* [email protected] [mailto: >[email protected]] *Namens *Dunlap, Zachariah >*Verzonden:* maandag 13 januari 2014 16:13 >*Aan:* [email protected] >*Onderwerp:* [MarkLogic Dev General] Backing up MarkLogic > > > >We are considering simply backing up the ?\Program Files\MarkLogic? folder >on each machine in our cluster using Amazon Glacier instead of making >backups using the ?Backup & Restore? feature. > > > >We?d love to get some feedback from others to try and helps us weigh the >pros and cons of simply backing up the data on the disk, vs. using >MarkLogic?s backup feature. > > > >Thank you all in advance for your thoughts. > > > >-Zach > > > >The information contained in this communication is intended for the use >of the designated recipients named above. If the reader of this >communication is not the intended recipient, you are hereby notified >that you have received this communication in error, and that any review, >dissemination, distribution or copying of this communication is strictly >prohibited. If you have received this communication in error, please >notify The Associated Press immediately by telephone at +1-212-621-1898 >and delete this email. Thank you. >[IP_US_DISC] > > > >msk dccc60c6d2c3a6438f0cf467d9a4938 >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >http://developer.marklogic.com/pipermail/general/attachments/20140113/66bf >6e12/attachment-0001.html > >------------------------------ > >Message: 3 >Date: Mon, 13 Jan 2014 10:06:04 -0800 >From: Michael Blakeley <[email protected]> >Subject: Re: [MarkLogic Dev General] Backing up MarkLogic >To: MarkLogic Developer Discussion <[email protected]> >Message-ID: <[email protected]> >Content-Type: text/plain; charset=windows-1252 > >In general it is a bad idea to do anything with the database's >filesystem. Rolling your own backup system is dangerous because any >updates during the backup window will almost certainly corrupt the >backup. When this happens the corrupted backup contains some files from >timestamp A and other files from timestamp B, C, etc. You won't find out >about this until you try to restore, because the filesystem doesn't >reveal the database state. So the backup will fail just when you need it. > >The built-in online backup feature knows about the database state, so it >can create a consistent, reliable backup at a single timestamp. Without >any special knowledge about your application, you should use a >conventional database backup. > >However there are some special cases where filesystem can work. The most >basic is to shut down the cluster before taking the backup. With the >database halted there are no updates, and therefore the filesystem state >is consistent. > >Extending this idea, you can leave MarkLogic running, but at the same >time ensure that there are no updates during the backup window. The best >way to do this is with the forest update state, as described at >http://docs.marklogic.com/guide/admin/forests#id_72520 in the docs. For >example you could put all the database forests into flash-backup mode, >take the filesystem backup, then resume updates. Note that any update >requests made during the backup window will queue and retry. As the name >implies, this is designed to work with very fast filesystem snapshot >mechanisms, so that the delayed updates do not have to wait long. Also >note that flash-backup adds a certain amount of complexity to the backup >system. > >In most cases it is best to use a conventional backup. > >-- Mike > >On 13 Jan 2014, at 07:13 , Dunlap, Zachariah <[email protected]> wrote: > >> We are considering simply backing up the ?\Program Files\MarkLogic? >>folder on each machine in our cluster using Amazon Glacier instead of >>making backups using the ?Backup & Restore? feature. >> >> We?d love to get some feedback from others to try and helps us weigh >>the pros and cons of simply backing up the data on the disk, vs. using >>MarkLogic?s backup feature. >> >> Thank you all in advance for your thoughts. >> >> -Zach >> >> >> The information contained in this communication is intended for the use >> of the designated recipients named above. If the reader of this >> communication is not the intended recipient, you are hereby notified >> that you have received this communication in error, and that any review, >> dissemination, distribution or copying of this communication is strictly >> prohibited. If you have received this communication in error, please >> notify The Associated Press immediately by telephone at +1-212-621-1898 >> and delete this email. Thank you. >> [IP_US_DISC] >> >> >> msk dccc60c6d2c3a6438f0cf467d9a4938 >> >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general > > > >------------------------------ > >_______________________________________________ >General mailing list >[email protected] >http://developer.marklogic.com/mailman/listinfo/general > > >End of General Digest, Vol 115, Issue 14 >**************************************** _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
