I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution.
It is not enough to just backup owner keys to the blockchain when it comes to stealth. Stealth transfers (unlike simply blinded transfers) don't publicly signal to the receiver that the transaction is meant for them. This is why with TITAN in pre-1.0 BitShares you needed to scan the entire blockchain with your private keys. In BitShares 2.0, forcing users to scan the entire blockchain is not expected. So a stealth transfer sender needs to communicate some information out-of-band. If I am not mistaken, the minimal amount of information that needs to be communicated out-of-band is a (block number, transaction number) tuple, i.e. a pointer to the transaction in the blockchain that contains the stealth transfer. With this information, I believe the receiver could easily request the transaction in question from the server (which should be small in size), and using their stealth-related private key quickly verify if in fact it contains a stealth transfer to them (and also decrypt the blinded amounts). But without this information, the receiver would not even be made aware of the transfer and thus would not have access to the funds to spend.
I believe that it should in theory be possible to follow the chain of stealth transfers (as in inputs to one stealth transfer consuming outputs of a previous one in the chain) to minimize the number of "transaction pointers" a client needs to keep to be able to fully restore all stealth transfers and thus all of their balances from scratch (assuming they also have their private keys). I think it would only be necessary to keep "transaction pointers" to transactions with the property of containing stealth transfer operation(s) that have output balances accessible by the user (with the exception of ones that would be redundant because the transaction they point to can already be accessed by going backwards along the stealth transfer transaction chain from a newer transaction with the aforementioned property). It could then be possible to take the set of all necessary "transaction pointers" grouped by each account in the wallet to be backed up, subtract that set by the corresponding set computed as of the last backup operation to the blockchain (empty set if this is the first time), encode the contents of the resulting set into a compact string, encrypt it using a private memo key of one of the accounts (the one designated as the account to do backups on), and then publish that string as a custom transaction under the backup account. A client starting from nothing more than a brain key (from which all the other relevant private keys can be deterministically derived), could then follow a procedure to use the data published to the blockchain to quickly (and with reasonable network bandwidth) recover all balances and all relevant transactions (including stealth ones).
Despite the above optimizations, there might still be a moderate amount of data to publish in the custom transaction to backup all the balances and stealth transfers. And each time a backup would be published, it would cost the user some transaction fee. Furthermore, for privacy reasons it would make sense to not publish a custom transaction backup immediately after each time the user receives a stealth transfer as that could potentially link the receiver of the stealth transfer to the backup account (though the link wouldn't necessarily be obvious). So, I would imagine backups like these would be used with less frequency. Instead, backing up the encrypted wallet to the host that provides the client software would be a more convenient solution. However, having a blockchain based backup as I described above would still be a nice addition as a further backup in the unusual case where the host disappears (and the user also makes a mistake and loses the wallet data stored locally with the client at the same time). Even if the blockchain backup isn't very recent, it might still help recover some partial funds in this worst case scenario. And best of all, assuming my understanding of the existing blockchain protocol is correct, the procedure I described above can be implemented by the client alone and doesn't require any changes to the blockchain protocol or the witness_nodes.