I don't understand how the creation of a snapshot causes any load whatsoever. By definition, a snapshot is a hard link of an existing SSTable. The SSTable is not being physically copied so there is no disk I/O, it's just a reference to an inode. 

--
Ray  //o-o\\



On Tue, Nov 5, 2013 at 8:09 PM, Aaron Turner <synfinatic@gmail.com> wrote:
Why not just have a small DC/ring of nodes which you just do your
snapshots/backups from?

I wouldn't take nodes offline from the ring just to back them up.

The other option is to add sufficient nodes to handle your existing
request I/O + backups.  Sounds like you might be already I/O
constrained.
--
Aaron Turner
http://synfin.net/         Twitter: @synfinatic
https://github.com/synfinatic/tcpreplay - Pcap editing and replay
tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin


On Tue, Nov 5, 2013 at 4:36 PM, Sridhar Chellappa
<schellap2009@gmail.com> wrote:
> We are running into problems where Backup jobs are taking away a huge
> bandwidth out of the C* nodes. While we can schedule a particular timing
> window for backups alone, the request pattern is so random; there is no
> particular time where we can schedule backups, periodically.
>
> My current thinking is to run backups against a replica that does not serve
> requests. Questions:
>
> Is it the right strategy?
> if it is - how do I pull a replica out from serving requests ?
> If not, what is the right  backup strategy ?