Merge pull request #245721 from MSFTeegarden/patch-34

Update cache-administration.md

Author: prmerger-automator[bot]

articles/azure-cache-for-redis/cache-administration.md

@@ -38,7 +38,7 @@ The effect on your client applications varies depending on which nodes you reboo
 
 * **Primary** - When the primary node is rebooted, Azure Cache for Redis fails over to the replica node and promotes it to primary. During this failover, there may be a short interval in which connections may fail to the cache.
 * **Replica** - When the replica node is rebooted, there's typically no effect on the cache clients.
-* **Both primary and replica** - When both cache nodes are rebooted, you lose all data in the cache and connections to the cache fail until the primary node comes back online. If you have configured [data persistence](cache-how-to-premium-persistence.md), the most recent backup is restored when the cache comes back online. However, any cache writes that occurred after the most recent backup are lost.
+* **Both primary and replica** - When both cache nodes are rebooted, Azure Cache for Redis will attempt to gracefully reboot both nodes, waiting for one to finish before rebooting the other. Typically, data loss does not occur. However, data loss can still occur do to unexpected maintenance events or failures. Rebooting your cache many times in a row increases the odds of data loss.
 * **Nodes of a premium cache with clustering enabled** - When you reboot one or more nodes of a premium cache with clustering enabled, the behavior for the selected nodes is the same as when you reboot the corresponding node or nodes of a non-clustered cache.
 
 ## Reboot FAQ
@@ -51,7 +51,7 @@ The effect on your client applications varies depending on which nodes you reboo
 
 ### Which node should I reboot to test my application?
 
-To test the resiliency of your application against failure of the primary node of your cache, reboot the **Primary** node. To test the resiliency of your application against failure of the replica node, reboot the **Replica** node. To test the resiliency of your application against total failure of the cache, reboot **Both** nodes.
+To test the resiliency of your application against failure of the primary node of your cache, reboot the **Primary** node. To test the resiliency of your application against failure of the replica node, reboot the **Replica** node.
 
 ### Can I reboot the cache to clear client connections?
 
@@ -64,7 +64,7 @@ Yes, if you reboot the cache, all client connections are cleared. Rebooting can
 
 ### Will I lose data from my cache if I do a reboot?
 
-If you reboot both the **Primary** and **Replica** nodes, all data in the cache (or in that shard when you're using a premium cache with clustering enabled) might be lost. However, the data might not be lost either. If you have configured [data persistence](cache-how-to-premium-persistence.md), the most recent backup is restored when the cache comes back online. However, any cache writes that have occurred after the backup was made are lost.
+If you reboot both the **Primary** and **Replica** nodes, all data in the cache (or in that shard when you're using a premium cache with clustering enabled) like likely be safe. However, the data may be lost in some cases. Rebooting both nodes should be taken with caution.
 
 If you reboot just one of the nodes, data isn't typically lost, but it still might be. For example if the primary node is rebooted and a cache write is in progress, the data from the cache write is lost. Another scenario for data loss would be if you reboot one node and the other node happens to go down because of a failure at the same time. For more information about possible causes for data loss, see [What happened to my data in Redis?](https://gist.github.com/JonCole/b6354d92a2d51c141490f10142884ea4#file-whathappenedtomydatainredis-md)