More cleanup

Ping #2894

website/source/docs/concepts/ha.html.markdown

@@ -74,8 +74,8 @@ there is an error performing the forwarding. As such, a redirect address is
 always required for all HA setups.
 
 Some HA data store drivers can autodetect the redirect address, but it is often
-necessary to configure it manually via setting a value in the `backend`
-configuration block (or `ha_backend` if using split data/HA mode). The key for
+necessary to configure it manually via setting a value in the `storage`
+configuration block (or `ha_storage` if using split data/HA mode). The key for
 this value is `redirect_addr` and the value can also be specified by the
 `VAULT_REDIRECT_ADDR` environment variable, which takes precedence.
 
@@ -129,7 +129,7 @@ it will start cluster listeners, and when it becomes standby it will stop them.
 
 Similar to the `redirect_addr`, `cluster_addr` is the value that each node, if
 active, should advertise to the standbys to use for server-to-server
-communications, and lives in the `backend` (or `ha_backend`) block. On each
+communications, and lives in the `storage` (or `ha_storage`) block. On each
 node, this should be set to a host name or IP address that a standby can use to
 reach one of that node's `cluster_address` values set in the `listener` blocks,
 including port. (Note that this will always be forced to `https` since only TLS
@@ -138,10 +138,10 @@ connections are used between servers.)
 This value can also be specified by the `VAULT_CLUSTER_ADDR` environment
 variable, which takes precedence.
 
-## Backend Support
+## Storage Support
 
-Currently there are several backends that support high availability mode,
-including Consul, ZooKeeper and etcd. These may change over time, and the
+Currently there are several storage backends that support high availability
+mode, including Consul, ZooKeeper and etcd. These may change over time, and the
 [configuration page](/docs/configuration/index.html) should be referenced.
 
 The Consul backend is the recommended HA backend, as it is used in production

website/source/intro/getting-started/deploy.html.md

@@ -23,7 +23,7 @@ As a reminder, JSON files are also fully HCL-compatible; HCL is a superset of JS
 The configuration file for Vault is relatively simple. An example is shown below:
 
 ```javascript
-backend "consul" {
+storage "consul" {
   address = "127.0.0.1:8500"
   path = "vault"
 }
@@ -36,15 +36,15 @@ listener "tcp" {
 
 Within the configuration file, there are two primary configurations:
 
-  * `backend` - This is the physical backend that Vault uses for
-    storage. Up to this point the dev server has used "inmem" (in memory),
-    but in the example above we're using [Consul](https://www.consul.io),
-    a much more production-ready backend.
+  * `storage` - This is the physical backend that Vault uses for storage. Up to
+    this point the dev server has used "inmem" (in memory), but in the example
+    above we're using [Consul](https://www.consul.io), a much more
+    production-ready backend.
 
-  * `listener` - One or more listeners determine how Vault listens for
-    API requests. In the example above we're listening on localhost port
-    8200 without TLS. In your environment set `VAULT_ADDR=http://127.0.0.1:8200`
-    so the Vault client will connect without TLS.
+  * `listener` - One or more listeners determine how Vault listens for API
+    requests. In the example above we're listening on localhost port 8200
+    without TLS. In your environment set `VAULT_ADDR=http://127.0.0.1:8200` so
+    the Vault client will connect without TLS.
 
 For now, copy and paste the configuration above to a file called
 `example.hcl`. It will configure Vault to expect an instance of Consul
@@ -69,7 +69,7 @@ $ vault server -config=example.hcl
 ==> Vault server configuration:
 
          Log Level: info
-           Backend: consul
+           Storage: consul
         Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
 
 ==> Vault server started! Log data will stream in below: