I perform a cron backup every day, multiple times per day.
I dump all the collections and then put them each one of them in their
own tarball. My backup script is pretty much a custom script that serves
my own needs.
I do it for ~70 databases. Takes about ~20 minutes. The script runs on
PHP 7 / Centos and connects remotely on a debian system which is the
database server.
Just beware of this issue
(https://github.com/arangodb/arangodb/issues/2437) *when and if* you run
arangorestore *on the same DB server on a different database.
*
A simple workaround is to manipulate the JSON collection files and
change the collection IDs before arangorestore, haven't noticed any
issues with that approach.
On 08/30/2017 02:43 AM, Scott B. wrote:
My use case is as follows:
I have an application that uses ArangoDB as its primary database. My
application (the part that talks to ArangoDB) is a Java REST service.
Sometimes, when I upgrade my application, I need to make changes to
the underlying data in the ArangoDB database (for example, adding,
removing, or transforming document properties). To make things
easier, I want to automate this process. Meaning I want to
automatically kick-off a "data upgrade" when a new version of my app
runs for the first time. I have that part figured out and working.
However, I know there is always a potential that something happens
during the upgrade process, and not all of the data is "upgraded"
properly. Since ArangoDB does not support distributed transactions, I
need another mechanism to ensure I can "rollback" to my pre-upgrade
state and try again, or just keep using the old version of the app.
Ideally, I'd like a way to clone the database to a new database as a
backup prior to kicking off the upgrade using my Java app, perform the
upgrade, and then delete the clone "backup" once it is successful. It
seems like I have a few options:
1. Using the Java driver, iterate through all Collections, Graphs,
Indexes, etc in the current DB, and programmatically recreate them in
a new DB. This is "clean", since I can do it all in Java code, but
seems terribly inefficient (I'd have to transfer all of the data from
the DB server to the app server, then back, for every single record in
the database).
2. Use Foxx to do the same thing as above, but "locally". Seems more
efficient, but still not perfect (and I have zero Foxx experience, so
a bit of a learning curve).
3. Use Foxx or some other mechanism to remotely trigger an execution
of arangodump and/or arangoexport to dump the database before the upgrade.
Has anyone attempted anything similar in the past? Does anyone have
ideas on alternatives not mentioned above?
--
You received this message because you are subscribed to the Google
Groups "ArangoDB" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
George Kafataridis
Web Developver at Nelios.com <http://goo.gl/6YddTJ>
T +30 2146879950 <tel:00302146879950>
@ [email protected] <mailto:[email protected]>
nelios <http://goo.gl/6YddTJ>
Nelios.com Ltd
29 Agiou Markou & Aiolou St. 10560 (1st floor), Athens
fb <https://www.facebook.com/nelioscom/> twitter
<https://twitter.com/nelios> google plus
<https://plus.google.com/+Nelios> linkedin
<https://www.linkedin.com/company/nelios-com> rss
<http://feeds.feedburner.com/NelioscomBlog?format=xml>
Disclaimer This email may contain confidential and privileged material
for the sole use of the intended recipient. Any review or distribution
by others is strictly prohibited. If you are not the intended recipient
please contact the sender and delete all copies.
--
You received this message because you are subscribed to the Google Groups
"ArangoDB" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
