From oak-dev-return-87-apmail-jackrabbit-oak-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Mon Mar 12 11:15:22 2012 Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D1ED79C8B for ; Mon, 12 Mar 2012 11:15:22 +0000 (UTC) Received: (qmail 81439 invoked by uid 500); 12 Mar 2012 11:15:22 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 81411 invoked by uid 500); 12 Mar 2012 11:15:22 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 81402 invoked by uid 99); 12 Mar 2012 11:15:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Mar 2012 11:15:22 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com designates 74.125.82.170 as permitted sender) Received: from [74.125.82.170] (HELO mail-we0-f170.google.com) (74.125.82.170) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Mar 2012 11:15:16 +0000 Received: by werh12 with SMTP id h12so6453444wer.1 for ; Mon, 12 Mar 2012 04:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=+6+S1I1/XZpkZoOt0rGYb/e6wnPvEnRYjmDgmp/tPMI=; b=PJekeRw40SLysrD1dxLwga65rvdXgJNetCH8nUzjrYp/OidIb1ddYnWn16L+AADYv4 eWyzi84xtWsSGC3wiYQNB1nrORDuUjAUctKdPCRwizW6pdHZ0FyeZVfpgqK3BQG2fYSb 6y8i8YgXYXTXAQ4POowq5dyh9EOpRRsP3ht6G3RdIXKHtl3vF6VDtjKl1UbnD9DXE7kP XFT47bKx1dwaMoOAfk/sUo5t0pt5HfHzqu/HC4emezvrGZEJ3y1RgGtwlGDBgf1Aqprx 41E2igfoYEUGr9DhHMOmxDE7I2nv4dRaZUxYHvA+J9/MdalAWdX632eJR9ir+nQW06nk GIkA== Received: by 10.180.101.72 with SMTP id fe8mr26363733wib.4.1331550895173; Mon, 12 Mar 2012 04:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.102.134 with HTTP; Mon, 12 Mar 2012 04:14:35 -0700 (PDT) In-Reply-To: <9C0FC4C8E9C29945B01766FC7F9D389816E3CC9C70@eurmbx01.eur.adobe.com> References: <9C0FC4C8E9C29945B01766FC7F9D389816E3CC9C70@eurmbx01.eur.adobe.com> From: Jukka Zitting Date: Mon, 12 Mar 2012 12:14:35 +0100 Message-ID: Subject: Re: Online backup To: oak-dev@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org Hi, On Mon, Mar 12, 2012 at 12:05 PM, Marcel Reutegger wrote: >> 2) Assuming we get the clustering architecture right (which we >> should), it should be possible to start a new read-only node to an >> existing cluster, wait for it to synchronize all existing content from >> the rest of the cluster, and finally stop this backup node. The result >> should be a complete, runnable copy of the repository. > > this however also assumes that each cluster node has a complete copy > of the repository. I'd rather be in favor of a cluster solution that > distributes the repository across multiple machines for improved > scalability. Right, sharding is an added complexity. Once a repository reaches the size where sharding is required, the traditional approach of backing up the repository to a single backup server or tape no longer works. In such cases the backup itself probably also needs to be sharded, which probably is best achieved by starting a full set of shards instead of just a single node for the backup. BR, Jukka Zitting