such a script would surely help, it needs only 2 extra parameters.. for creating backups :
--to-tableNamePrefix server_com___ aka --totnp server_com___ and for restoring backups : --from-tableNamePrefix server_com___ aka --fromtnp server_com___ which would specify as the name implies, an interface to create backups of multiple couchdb sites on a single other machine that can even host it's own version of live data related to the domain name it serves. i really really hope you can find the time sometime within the next year to add this parameter ;) i kinda need it to even launch my biz, based on the seductiveapps.com code that i worked for eh, over a decade, on... if you don't make this change, let me know, so i can make it myself to the script you published (assuming you published with it's source code for a moment). i can republish it in my seductiveapps for ya, or you can just eventually rip it back and re-publish it yourself.... and if you want to rename the parameters, feel free to of course. so long as i can specify that prefix. maybe you should add a suffix option just to be sure, in one go. thanks for your efforts so far though :) On Wed, Jun 19, 2019 at 10:34 AM Adrien Vergé <adrien.ve...@tolteck.com> wrote: > Hello Rene, > > About your question 1), I created a small utility script to replicate a > whole > CouchDB server to another. You can find at > https://github.com/adrienverge/coucharchive and run it with: > > coucharchive replicate --from http://r...@server.com:5984 \ > --to http://ad...@other-server.com:5984 > > I hope this helps. > > Adrien > > Le mer. 19 juin 2019 à 02:16, Rene Veerman <seductivea...@gmail.com> a > écrit : > >> as far as a i know, i can't specify a port for replication, except for the >> http address to the database to be replicated. >> this is in /_utils, replication tab on the left of the screen. >> >> i also need something to automatically copy all databases to another >> server. >> >> On Thu, Jun 13, 2019 at 2:47 PM Robert Samuel Newson <b...@rsn.io> wrote: >> >> > Hi, >> > >> > The replicator contacts the source and target on whichever port you >> > specify, using the http protocol. port 4369 is erlang’s port daemon >> mapper, >> > unrelated to replication. >> > >> > As already noted, the _replicator database is the mechanism for >> defining a >> > replication that will survive server reboots, whether you decide that >> the >> > replication just gets the docs from source to target and then ends, or >> > whether it runs indefinitely until you delete the replication. >> > >> > B. >> > >> > > On 12 Jun 2019, at 13:31, Sinan Gabel <sinan.ga...@gmail.com> wrote: >> > > >> > > You should use the _replicator database (and not one-off >> replications, >> > > even if continuous), these also restart after reboot. >> > > >> > > As far as I know - someone else can correct me if I am wrong - the >> > > _replicator database speaks through Erlang port, perhaps port 4369. >> > > Thus you should check if the servers can speak to each other on the >> > > necessary ports. >> > > >> > > On Wed, 12 Jun 2019 at 11:23, Rene Veerman <seductivea...@gmail.com> >> > wrote: >> > > >> > >> i'm trying to set up replication of my databases, but i'm stuck in 3 >> > ways : >> > >> >> > >> 1) i can't seem to be able to set up automated backup of all >> databases >> > on a >> > >> couchdb server to another server. >> > >> >> > >> 2) when i try to replicate a single database from couchdb servers >> which >> > >> have no problem accessing databases via javascript or PHP, from the >> > /_utils >> > >> interface, the interface throws an error at me : "Failed to create >> the >> > >> _replicator database." >> > >> >> > >> 3) i don't know, and the docs don't exactly spell this out either, >> > >> whether or not a continuous replication job will survive a reboot of >> > either >> > >> or both of the machines involved in the replication. >> > >> >> > >> if someone more experienced could shed some light on this, i'd be >> very >> > >> grateful. >> > >> >> > >> > >> >
