Dear Anthony,

As you specified in your question as to Basho's official method, may I refer 
you to https://docs.basho.com/riak/kv/2.1.4/using/cluster-operations/backing-up/

Backing up an entire Riak cluster in one operation is difficult because of the 
way Riak operates. It is impossible, without downtime, to say that no requests 
are currently in-flight between nodes or only written 2 out of 3 replicas, etc. 
For this reason we recommend users back up their nodes in a rolling fashion. 
Taking a node down, backing up the data/configuration/ring, and then restarting 
the node. Restoring from these backups is simple. Move the data directory 
backups, config, and ring back to their appropriate location and start the node.

But even with all those explanations, it's clear that for realtime distributed 
systems there's really not a truly "point in time" backup. This has been 
resolved in a Riak KV cluster via MDC replication. Should you want to consider 
MDC replication, we would highly recommend bi-directional replication as non 
bi-directional replication does not propagate tombstones which will lead to 
siblings on the standby cluster.

One thing to bear in mind is that Riak CS was never officially tested or 
approved with Riak KV 2.2.x series. As such, if you do not have an Enterprise 
Edition copy of Riak KV 2.1.4 or earlier, there is no officially approved way 
to run an MDC solution with Riak CS.

If MDC is not an option, one possible way to be able to replicate to a standby 
cluster is to do it at the application level. Maybe have the app communicate to 
2 CS nodes, the 1st CS node communicates to the production Riak KV cluster and 
the 2nd one communicates to the standby Riak KV cluster. This way, both the 
production and standby KV clusters get updated at around the same time.

tl;dr;
The only truly safe ways to back up a Riak cluster that is using Riak CS would 
be to:
1. Stop the cluster completely and do a full data back up via your preferred 
method e.g. snapshots, tarballs etc.
2. Licensing permitting, use MDC to replicate to another cluster.
3. Create something yourself to work at the application level that would mirror 
all commands.

Hope this helps,

Nicholas

From: riak-users <riak-users-boun...@lists.basho.com> On Behalf Of Bryan Hunt
Sent: 25 April 2018 22:50
To: riak-users <riak-users@lists.basho.com>
Subject: Re: Riak CS Backup Solutions

Anthony,

Your snapshot solution is not bad if you just want a daily version you can roll 
back to for disaster recovery.

I presume :

1. You’re running on VM’s
2. You stop the world at the time of the snapshot

Riak CS makes multiple (3 by default) copies of your data and generally 
speaking, stores them onto multiple physical servers with the following caveats 
:

1. Verify that the partitions are evenly spread across the machines, sometimes 
old Riak puts two copies of the data on a single physical machine.
2. Always run a cluster of 5 or more machines.
3. Take care that you’re not storing all your data on the same physical device 
(SAN server in the basement anyone?) ).

I suppose the reason you want backups is to mitigate the situation where an 
adversary gets inside your servers and begins silently deleting or tampering 
with data, in which case, snapshots are prudent.

If you wanted to do something more sophisticated, you could try :

1. Re-building your cluster using the soon to be released Riak 2.2.5.
2. Replicate off site to a physically remote location
3. More regularly perform snapshots there (as they won’t impact latencies on 
your main Riak CS cluster)

Does that make sense? Any questions?

Bryan





On 25 Apr 2018, at 14:30, Anthony Valenti 
<anthony.vale...@inmar.com<mailto:anthony.vale...@inmar.com>> wrote:


We are looking to improve on our Riak CS backup strategy.  We have had Riak CS 
in place for a while and we are currently taking a snapshot of each server.  
I'm not sure is this is the best method in terms of recoverability, space used, 
timeliness or the backups, etc.  What methods has anyone else used?  What is 
the basho recommended solution?

Thanks,
Anthony Valenti


********************************************


Inmar Confidentiality Note:  This e-mail and any attachments are confidential 
and intended to be viewed and used solely by the intended recipient.  If you 
are not the intended recipient, be aware that any disclosure, dissemination, 
distribution, copying or use of this e-mail or any attachment is prohibited.  
If you received this e-mail in error, please notify us immediately by returning 
it to the sender and delete this copy and all attachments from your system and 
destroy any printed copies.  Thank you for your cooperation.


Notice of Protected Rights:  The removal of any copyright, trademark, or 
proprietary legend contained in this e-mail or any attachment is prohibited 
without the express, written permission of Inmar, Inc.  Furthermore, the 
intended recipient must maintain all copyright notices, trademarks, and 
proprietary legends within this e-mail and any attachments in their original 
form and location if the e-mail or any attachments are reproduced, printed or 
distributed.

********************************************
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com<mailto:riak-users@lists.basho.com>
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Reply via email to