Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
From: Adam Kocoloski <kocolosk@apache.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: Backup for 2.x
Date: Thu, 8 Dec 2016 14:24:46 -0500
References: <VI1PR0502MB3069210A6BC461615642444EF4840@VI1PR0502MB3069.eurprd05.prod.outlook.com>
To: "dev@couchdb.apache.org Developers" <dev@couchdb.apache.org>
In-Reply-To: <VI1PR0502MB3069210A6BC461615642444EF4840@VI1PR0502MB3069.eurprd05.prod.outlook.com>
Message-Id: <E020200C-98B8-46E3-A208-888C3A46B0BB@apache.org>
archived-at: Thu, 08 Dec 2016 19:24:55 -0000

Kinda.

Yes, every file in the shards folder is using the same basic =
copy-on-write file format as v1. The challenge is that a single logical =
database has multiple physical shards potentially spread across multiple =
hosts. Capturing the state of each of those shard files _at the same =
point in time_ can be a challenge, but is technically the sort of thing =
that=E2=80=99s required to get to the same consistency semantics as the =
file-based backup option in v1. If you copy the files at different =
points in time the restored database won't correspond to a snapshot of =
the database at any particular point in time.

Using a snapshotting filesystem (LVM, ZFS, etc.) and copying the =
_snapshot_ of the shards directory to a different host is something =
worth considering here. Cheers,

Adam

> On Dec 8, 2016, at 5:23 AM, Reddy B. <reddy.b@live.fr> wrote:
>=20
> Hi all,
>=20
> The ability to backup as easily as by copying a file was really useful =
in version 1 as it allowed us to take advantage of a large array of =
general purpose backup tools.
>=20
> In 2.x, is it safe to just copy the "shards" folder assuming that we =
intend to "restore" it on a cluster having the same configuration ?