From user-return-24477-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri May 10 15:45:58 2013
Return-Path:
X-Original-To: apmail-couchdb-user-archive@www.apache.org
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 1437EF1FF
for ; Fri, 10 May 2013 15:45:58 +0000 (UTC)
Received: (qmail 20862 invoked by uid 500); 10 May 2013 15:45:56 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 20715 invoked by uid 500); 10 May 2013 15:45:56 -0000
Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: user@couchdb.apache.org
Delivered-To: mailing list user@couchdb.apache.org
Received: (qmail 20705 invoked by uid 99); 10 May 2013 15:45:56 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 May 2013 15:45:56 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
tests=RCVD_IN_DNSWL_NONE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of virtualandy@gmail.com designates 209.85.192.176 as permitted sender)
Received: from [209.85.192.176] (HELO mail-pd0-f176.google.com) (209.85.192.176)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 May 2013 15:45:49 +0000
Received: by mail-pd0-f176.google.com with SMTP id x10so2873607pdj.35
for ; Fri, 10 May 2013 08:45:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=x-received:subject:references:from:content-type:x-mailer
:in-reply-to:message-id:date:to:content-transfer-encoding
:mime-version;
bh=MR3E0aeDMqIo4PnLEdu40EfAr8+pdy4R8gVtTkh9toc=;
b=eFPh2zZGa5hJ9V3VJulXNObfwiKNNxlbFiuMdvmKtoiWon9oHRv6JlcJ3GtqRJ8Xt8
rsCXPWypJyGS0T0lPf3vV00sS/4IAD3umH54Y5T5UONWQIZbtS5oBm7gb4l1vuXyMY25
IzeqC3Wg1Yb+/qodyV+ydJy/V8Y/CItDMFCo3vzknqlFIZ4w0XMmYx42uP/+Xl838ZB2
3X4PEgOENCFcjEQgTbM9FlvxwE75ZtZMrjzTEQk1BBSNOQGDvyzb6TPU8xskixM/79Ij
jtf0tSdFg3RALYXMBp1emQq8XmQjTB9Rf1nATzu3dKlqoSS1bBeRUgBDRH9f7UEFDQAJ
bz1w==
X-Received: by 10.68.136.168 with SMTP id qb8mr17828780pbb.20.1368200728330;
Fri, 10 May 2013 08:45:28 -0700 (PDT)
Received: from [10.193.191.147] (mobile-166-147-081-112.mycingular.net. [166.147.81.112])
by mx.google.com with ESMTPSA id 10sm3175986pbm.0.2013.05.10.08.45.26
for
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 10 May 2013 08:45:27 -0700 (PDT)
Subject: Re: Best way to backup and restore after going offline
References: <26DFFECD-2D89-45EC-A003-E824445F2BB8@vpro.nl>
From: Andy Ennamorato
Content-Type: text/plain;
charset=us-ascii
X-Mailer: iPhone Mail (10B329)
In-Reply-To: <26DFFECD-2D89-45EC-A003-E824445F2BB8@vpro.nl>
Message-Id: <015D0300-F4D0-4949-BFB8-AC835292F1BE@gmail.com>
Date: Fri, 10 May 2013 09:45:23 -0600
To: "user@couchdb.apache.org"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
X-Virus-Checked: Checked by ClamAV on apache.org
Nils,
Thanks that was definitely helpful.
We're having issues replicating but once it finishes we'll give this a shot.=
Andy=20
Sent from my iPhone
On May 7, 2013, at 3:59 PM, Nils Breunese wrote:
> andy e wrote:
>=20
>> We're trying to replicate a database while connected to the great big
>> Internet (the npm repo, actually). But after it is finished replicating w=
e
>> need to take our copy and run it in a different and offline environment.
>>=20
>> What's the best way to proceed? Just backup the database file(s), then co=
py
>> them over to our offline instance (we do this via disc/usb/etc). Anything=
>> to be aware of when doing this ("make sure to grab this file", "run this
>> command first before importing")?
>=20
> A single .couch file represents a single database. You can just copy over t=
hese files. There's even no need to shut down the source instance (unlike wh=
en using something like MySQL for instance).
>=20
> If you also want to copy over the generated view indexes, you can also cop=
y over the hidden directories in the data directory. This only makes sense i=
f regenerating these indexes on the target instance takes a lot of time.
>=20
>> Is there any way to pick up just the changed documents, so that the secon=
d
>> time we do this, we only have to transfer what is new (versus copying the=
>> entire thing again)? That's not too big of a deal if so but would be a
>> nice-to-have.
>=20
> Updating your online copy could be done by rerunning replication from npm t=
o your online instance. You could use rsync to just copy over the difference=
s in the file at the block level. Or you could start a second CouchDB instan=
ce on the offline machine (use a different IP address and/or port) using the=
updated database files on the transfer medium and run replication between t=
hose two CouchDB instances on the offline machine.
>=20
> HTH, Nils.