As for the chances that TTN loses the keys and to not join too often to avoid duplicate nonces from being rejected, a transcript from Slack, October 29th:
@arjanvanb 10:43 AM
@htdvisser […] do you expect TTN could ever lose all the keys (server side)? Is some backup in place?
@htdvisser 12:02 PM
As you may know, we use Redis, an in-memory data store to store devices. This gives us very high performance (messages being handled in a couple of µs), but indeed has a higher risk of data loss. Redis has two mechanisms for persistence, and we use both of them. The first is to write every transaction to an append-only file, which, in case of a power outage, we can replay to restore the state. In the worst case, we may lose the last transaction if the disk write was interrupted. The second mechanism is to make periodic dumps of the entire data store. The dump frequency depends on the number of writes, but it happens at least every 10 minutes. This dump can be used if, for some reason, the first mechanism fails.
Next to this, we have an off-site storage facility where we keep hourly, daily and weekly backups of those dump files, plus all configuration files that are needed to fully restore the server to the exact state at that point in time. These backups should only be needed if the server’s SSD can not be recovered for some reason.
@arjanvanb 12:53 PM
So […] for TTN there should be no reason for @dbrgn’s comment “right now, rejoining every few days is probably the best approach to make sure that the device survives new keys, should that ever be necessary”?
@htdvisser 1:07 PM
I can’t think of any reason to do that. In fact, I can only think of a reason not to join that often, which is that every join needs to use a unique 2-byte nonce. This means that a device can do 65.000 joins in its lifetime. That’s perfectly fine if the nonces are incrementing (as is the case in LoRaWAN 1.1), but if they are random (in many LoRaWAN 1.0 devices) the chances of a successful join will quickly become smaller over time
All said, users could backup the TTN-generated keys as well. And keys could be compromised too, in which case you might want to tell a node to get new keys. LoRaWAN 1.1 supports that.