Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-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 CAE131024E for ; Sat, 7 Dec 2013 10:24:21 +0000 (UTC) Received: (qmail 81965 invoked by uid 500); 7 Dec 2013 10:24:11 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 81922 invoked by uid 500); 7 Dec 2013 10:24:06 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 81909 invoked by uid 99); 7 Dec 2013 10:24:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Dec 2013 10:24:02 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.160.51] (HELO mail-pb0-f51.google.com) (209.85.160.51) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Dec 2013 10:23:57 +0000 Received: by mail-pb0-f51.google.com with SMTP id up15so2489405pbc.24 for ; Sat, 07 Dec 2013 02:23:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=voBAtetmsmaqAyoNOtTS9lQRynWBpKWmnRIVTDUFKn8=; b=fL+s1+d9QeMhLPGeQA99ZulskLMnR+F6Pobu4ftkJprPH0ioXm4dowoj8SwnUbcC9d EFZ7eFW/OeQ7Jff6I1tYtQhpjIVTuRWAh6BXpOLBQYBIbtge3hUgzSdOmEFe0AY5GKBf fwOYS8uR1rg3ba1yOfog88vz3k842YWn5y9GxBJM9ZTNOuQvgVzsFB2rTAKTXldEKEeb gvaeFp+k2rWXtU75U+LtsCgfi4ohjIZt+yoEBe4VzCm8LAPryjLltJYnYzP3GJ5V2C9y uWAIKPc3vnoMmAWLx+7QMBulFm2OB/946CDln2SrhNozLLU+KybOKDpJsOx8qFbLhISJ mNZg== X-Gm-Message-State: ALoCoQnYVQwt3kebitkdiFP8QuyCsU2463l+ctVkE6tyiGoEVqVhh1d75a76UITnJvf1Oqt9U7aJ MIME-Version: 1.0 X-Received: by 10.66.119.172 with SMTP id kv12mr9413089pab.34.1386411815528; Sat, 07 Dec 2013 02:23:35 -0800 (PST) Received: by 10.68.55.230 with HTTP; Sat, 7 Dec 2013 02:23:35 -0800 (PST) In-Reply-To: References: <1C31524A-3CDD-4B22-AC2D-7BAEA1908AE2@s1mbi0se.com.br> Date: Sat, 7 Dec 2013 11:23:35 +0100 Message-ID: Subject: Re: help on backup muiltinode cluster From: Andre Sprenger To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=e89a8ffbac1dc7025504ecef2796 X-Virus-Checked: Checked by ClamAV on apache.org --e89a8ffbac1dc7025504ecef2796 Content-Type: text/plain; charset=ISO-8859-1 If you lose RF + 1 nodes the data that is replicated to only these nodes is gone, good idea to have a recent backup than. Another situation is when you deploy a bug in the software and start writing crap data to Cassandra. Replication does not help and depending on the situation you need to restore the backup. 2013/12/7 Jason Wee > Hmm... cassandra fundamental key features like fault tolerant, durable and > replication. Just out of curiousity, why would you want to do backup? > > /Jason > > > On Sat, Dec 7, 2013 at 3:31 AM, Robert Coli wrote: > >> On Fri, Dec 6, 2013 at 6:41 AM, Amalrik Maia wrote: >> >>> hey guys, I'm trying to take backups of a multi-node cassandra and save >>> them on S3. >>> My idea is simply doing ssh to each server and use nodetool to create >>> the snapshots then push then to S3. >>> >> >> https://github.com/synack/tablesnap >> >> So is this approach recommended? my concerns are about inconsistencies >>> that this approach can lead, since the snapshots are taken one by one and >>> not in parallel. >>> Should i worry about it or cassandra finds a way to deal with >>> inconsistencies when doing a restore? >>> >> >> The backup is as consistent as your cluster is at any given moment, which >> is "not necessarily". Manual repair brings you closer to consistency, but >> only on data present when the repair started. >> >> =Rob >> > > --e89a8ffbac1dc7025504ecef2796 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

If you lose RF=A0+ 1= nodes the data that is replicated to only these nodes is gone, good idea t= o have a recent backup than. Another situation is when you deploy a bug in = the software and start writing crap data to Cassandra. Replication does not= help and depending on the situation you need to restore the backup.=


2013/12/7 Jas= on Wee <peichieh@gmail.com>
Hmm... cassandra fundamental key features like fault toler= ant, durable and replication. Just out of curiousity, why would you want to= do backup?

/Jason


On Sat, Dec 7, 2013 at 3:31 AM, Robert C= oli <rcoli@eventbrite.com> wrote:
On Fri, Dec 6, 2013 at 6:41 AM, Amalrik Maia <amalr= ik@s1mbi0se.com.br> wrote:
hey guys, I'm trying to take backups of a multi-node cassandra and save= them on S3.=A0
My idea is si= mply doing ssh to each server and use nodetool to create the snapshots then= push then to S3.=A0

https://github.com/synack/tablesnap

So is this approach recommended? my concerns are about inconsistencies th= at this approach can lead, since the snapshots are taken one by one and not= in parallel.=A0=A0
Should i worry about it or cassand= ra finds a way to deal with inconsistencies when doing a restore?

The backup is as consistent as your clus= ter is at any given moment, which is "not necessarily". Manual re= pair brings you closer to consistency, but only on data present when the re= pair started.

=3DRob=A0


--e89a8ffbac1dc7025504ecef2796--