You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Riak KV is a [clustered][concept clusters] system built to survive a wide range of
25
-
failure scenarios, including the loss of nodes due to network or
26
-
hardware failure. Although this is one of Riak's core strengths, it
27
-
cannot withstand _all_ failure scenarios. Like any storage system, it
28
-
remains susceptible to contingencies such as accidental or malicious
29
-
deletions. Many Riak users confront this possibility by backing up their
30
-
data, i.e. duplicating their database onto a different long-term storage
31
-
mechanism. This document covers how to perform such backups.
32
-
33
-
Riak backups can be performed using OS features or filesystems that
34
-
support snapshots, such as LVM or ZFS, or by using tools like rsync or
35
-
tar. Choosing your Riak backup strategy will largely depend on your
36
-
already-established backup methodologies, as well as the backend
37
-
configuration of your nodes. When backing up a node, it is important to
38
-
back up the data, ring, and configuration directories of your nodes.
39
-
40
-
Due to Riak's eventually consistent nature, backups can become slightly
41
-
inconsistent from node to node. Data could exist on some nodes and not
42
-
others at the exact time a backup is made. Any inconsistency will be
43
-
corrected once a backup is restored, either by Riak's [active anti-entropy](/riak/kv/2.0.0/learn/concepts/active-anti-entropy/) processes or when the object is read, via [read repair](/riak/kv/2.0.0/learn/concepts/active-anti-entropy/#read-repair-vs-active-anti-entropy).
44
-
45
-
Additionally, backups must be performed on a stopped node to prevent
46
-
data loss as a result of the background merging and compaction processes
47
-
of Riak's backends. Downtime of a node can be significantly reduced by
48
-
using an OS feature or filesystem that supports snapshotting.
Riak KV is a [clustered][concept clusters] system built to survive a wide range of failure scenarios, including the loss of nodes due to network or hardware failure. Although this is one of Riak KV's core strengths, it cannot withstand all failure scenarios.
27
+
28
+
Backing up data (duplicating the database on a different long-term storage system) is a common approach to mitigating potential failure scenarios.
29
+
30
+
This page covers how to perform backups of Riak KV data.
31
+
32
+
## Overview
51
33
52
-
The default Riak data, ring, strong consistency, and configuration
53
-
directories for each of the supported operating systems is as follows:
34
+
Riak KV backups can be performed using operating system features or filesystems that support snapshots, such as LVM or ZFS, or by using tools like rsync or tar.
54
35
55
-
<divclass="note">
56
-
<divclass="title">Note on upgrading</div>
57
-
If you are upgrading to Riak version 2.0 or later from a pre-2.0
58
-
release, you can use either your old <code>app.config</code>
59
-
configuration file or the newer <code>riak.conf</code> if you wish.
36
+
Choosing your Riak KV backup strategy will depend on your already-established backup methodologies and the backend configuration of your nodes.
60
37
61
-
If you have installed Riak 2.0 directly, you should use only
62
-
<code>riak.conf</code>.
38
+
The basic process for getting a backup of Riak KV from a node is as follows:
63
39
64
-
More on configuring Riak can be found in the [configuration files][config reference]
65
-
doc.
66
-
</div>
40
+
1. Stop Riak KV with `riak stop`.
41
+
2. Backup the appropriate data, ring, and configuration directories.
42
+
3. Start Riak KV.
43
+
44
+
Downtime of a node can be significantly reduced by using an OS feature or filesystem that supports snapshotting.
45
+
46
+
{{% note title="Backups and eventual consistency" %}}
47
+
Due to Riak KV's eventually consistent nature, backups can become slightly inconsistent from node to node.
48
+
49
+
Data could exist on some nodes and not others at the exact time a backup is made. Any inconsistency will be corrected once a backup is restored, either by Riak's [active anti-entropy](/riak/kv/2.0.0/learn/concepts/active-anti-entropy/) processes or when the object is read, via [read repair](/riak/kv/2.0.0/learn/concepts/active-anti-entropy/#read-repair-vs-active-anti-entropy).
50
+
{{% /note %}}
51
+
52
+
## OS-Specific Directory Locations
53
+
54
+
The default Riak KV data, ring, and configuration directories for each of the supported operating systems is as follows:
> The listings above show directories for data related to Riak's
134
-
[strong consistency][use ref strong consistency] feature. This feature is purely optional, so `/ensembles` directories will not exist in your installation if this feature is not being used. For more information, see [Using Strong Consistency](/riak/kv/2.0.0/developing/app-guide/strong-consistency) and [Managing Strong Consistency](/riak/kv/2.0.0/using/cluster-operations/strong-consistency).
135
-
136
131
## Performing Backups
137
132
138
-
> **Deprecation notice**
139
-
>
140
-
> In previous versions of Riak, there was a [`riak-admin backup`](/riak/kv/2.0.0/using/admin/riak-admin/#backup) command commonly used for
141
-
backups. This functionality is now deprecated. We strongly recommend
142
-
using the backup procedure documented below instead.
133
+
{{% note title="Deprecation notice" %}}
134
+
In previous versions of Riak KV, there was a [`riak-admin backup`](/riak/kv/2.0.0/using/admin/riak-admin/#backup) command commonly used for
135
+
backups. This functionality is now deprecated. We strongly recommend using the backup procedure documented below instead.
136
+
{{% /note %}}
137
+
138
+
Backups can be accomplished through a variety of common methods. Standard utilities such `cp`, `rsync`, and `tar` can be used, as well as any backup system already in place in your environment.
143
139
144
-
Backups of both Bitcask and LevelDB can be accomplished through a
145
-
variety of common methods. Standard utilities such `cp`, `rsync`, and
146
-
`tar` can be used as well as any backup system or method already in
147
-
place in your environment. Please remember that the node must *not* be
148
-
running while performing the backup.
140
+
A simple shell command, like those in the following examples, are sufficient for creating a backup of your Bitcask or LevelDB data, ring, and Riak KV configuration directories for a binary package-based Riak KV Linux
141
+
installation.
149
142
150
-
A simple shell command such as the following example is sufficient for
151
-
creating a backup of your Bitcask or LevelDB data, ring, and Riak
152
-
configuration directories for a binary package-based Riak Linux
153
-
installation. The following examples use `tar`:
143
+
The following examples use `tar`:
144
+
145
+
{{% note %}}
146
+
Backups must be performed on while Riak KV is stopped to prevent data loss.
147
+
{{% /note %}}
154
148
155
149
### Bitcask
156
150
@@ -166,6 +160,20 @@ tar -czf /mnt/riak_backups/riak_data_`date +%Y%m%d_%H%M`.tar.gz \
tar -czf /mnt/riak_backups/riak_data_`date +%Y%m%d_%H%M`.tar.gz \
167
+
/var/lib/riak/cluster_meta
168
+
```
169
+
170
+
### Search / Solr Data
171
+
172
+
```bash
173
+
tar -czf /mnt/riak_backups/riak_data_`date +%Y%m%d_%H%M`.tar.gz \
174
+
/var/lib/riak/yz
175
+
```
176
+
169
177
### Strong Consistency Data
170
178
171
179
Persistently stored data used by Riak's [strong consistency][use ref strong consistency] feature
@@ -176,26 +184,11 @@ tar -czf /mnt/riak_backups/riak_data_`date +%Y%m%d_%H%M`.tar.gz \
176
184
/var/lib/riak/ensembles
177
185
```
178
186
179
-
The basic process for getting a backup of Riak from a node is as
180
-
follows:
181
-
182
-
1. Stop the node with `riak stop`
183
-
2. Back up the appropriate data, ring, configuration, and strong consistency
184
-
(if applicable) directories as relevant to your operating system
185
-
3. Start the node
186
-
187
-
Consult the [Bitcask][plan backend bitcask] and [LevelDB][plan backend leveldb] documentation to learn more
188
-
about these backends.
189
-
190
187
## Restoring a Node
191
188
192
-
The method you use to restore a node will differ depending on a
193
-
combination of factors, including node name changes and your network
194
-
environment.
189
+
The method you use to restore a node will differ depending on a combination of factors, including node name changes and your network environment.
195
190
196
-
If you are replacing a node with a new node that has the same node name
197
-
(typically a fully qualified domain name or IP address), then restoring
198
-
the node is a simple process:
191
+
If you are replacing a node with a new node that has the same node name (typically a fully qualified domain name or IP address), then restoring the node is a simple process:
199
192
200
193
1. Install Riak on the new node.
201
194
2. Restore your old node's configuration files, data directory, and ring
@@ -217,15 +210,11 @@ additionally:
217
210
4. Plan the changes to the cluster with `riak-admin cluster plan`
218
211
5. Finally, commit the cluster changes with `riak-admin cluster commit`
219
212
220
-
> **Further information**
221
-
>
222
-
> For more information on the `riak-admin cluster` commands,
223
-
refer to our documentation on [cluster administration](/riak/kv/2.0.0/using/admin/).
213
+
{{% note %}}
214
+
For more information on the `riak-admin cluster` commands, refer to our documentation on [cluster administration](/riak/kv/2.0.0/using/admin/).
215
+
{{% /note %}}
224
216
225
-
For example, if there are five nodes in the cluster with the original
226
-
node names `riak1.example.com` through `riak5.example.com` and you wish
227
-
to restore `riak1.example.com` as `riak6.example.com`, you would execute
228
-
the following commands on `riak6.example.com`.
217
+
For example, if there are five nodes in the cluster with the original node names `riak1.example.com` through `riak5.example.com` and you wish to restore `riak1.example.com` as `riak6.example.com`, you would execute the following commands on `riak6.example.com`.
229
218
230
219
1. Join to any existing cluster node.
231
220
@@ -258,34 +247,20 @@ the following commands on `riak6.example.com`.
258
247
riak-admin cluster commit
259
248
```
260
249
261
-
Your [configuration files][config reference] should also be changed to match the new
262
-
name in addition to running the commands (the `-name` setting in
263
-
`vm.args`in the older config system, and the `nodename` setting in
264
-
`riak.conf`in the newer system). If the IP address of any node has
265
-
changed, verify that the changes are reflected in your configuration
266
-
files to ensure that the HTTP and Protocol Buffers interfaces are
267
-
binding to the correct addresses.
268
-
269
-
A robust DNS configuration can simplify the restore process if the IP
270
-
addresses of the nodes change, but the hostnames are used for the node
271
-
names and the hostnames stay the same. Additionally, if the HTTP and
272
-
Protocol Buffers interface settings are configured to bind to all IP
273
-
interfaces (0.0.0.0), then no changes will need to be made to your
274
-
configuration files.
275
-
276
-
When performing restore operations involving `riak-admin cluster
277
-
force-replace`, we recommend that you start only one node at a time and
278
-
verify that each node that is started has the correct name for itself
279
-
and for any other nodes whose names have changed.
280
-
281
-
To do this, first verify that the correct name is present your
282
-
configuration file. Then, once the node is started, run `riak attach` to
283
-
connect to the node. It may be necessary to enter an Erlang atom and
284
-
press enter to obtain a prompt, by typing `x.` and pressing enter. The
285
-
prompt obtained should contain the correct node name. Disconnect from
286
-
the attached session with `^d` (**Ctrl-d**). Finally, run `riak-admin
287
-
member_status` to list all of the nodes and verify that all nodes listed
288
-
have the correct names.
250
+
Your [configuration files][config reference] should also be changed to match the new name in addition to running the commands (the `-name` setting in`vm.args`in the older config system, and the `nodename` setting in`riak.conf`in the newer system).
251
+
252
+
If the IP address of any node has changed, verify that the changes are reflected in your configuration files to ensure that the HTTP and Protocol Buffers interfaces are binding to the correct addresses.
253
+
254
+
A robust DNS configuration can simplify the restore process if the IP addresses of the nodes change, but the hostnames are used for the node names and the hostnames stay the same. Additionally, if the HTTP and Protocol Buffers interface settings are configured to bind to all IP interfaces (0.0.0.0), then no changes will need to be made to your configuration files.
255
+
256
+
When performing restore operations involving `riak-admin cluster force-replace`, we recommend that you start only one node at a time and verify that each node that is started has the correct name for itself
257
+
and for any other nodes whose names have changed:
258
+
259
+
1. Verify that the correct name is present your configuration file.
260
+
2. Once the node is started, run `riak attach` to connect to the node. The prompt obtained should contain the correct node name.
261
+
- (It may be necessary to enter an Erlang atom by typing `x.` and pressing Enter)
262
+
3. Disconnect from the attached session with **Ctrl-G + q**.
263
+
4. Finally, run `riak-admin member_status` to list all of the nodes and verify that all nodes listed have the correct names.
0 commit comments