XSalsa20Poly1305 for encryption at rest

While you did not mention the source, here one. Actually, XSalsa family is described in Bernstein's paper;

• 2011, Extending the Salsa20 nonce, D.J.B.

Does the "X" in XSalsa20Poly1305 just mean a 192 bit nonce?

Yes, it means the nonce sizes of XSalsa is 192-bit while Salsa has 64-bit. This is so huge that even for random nonces one has to generate $2^{96}$ uniform nonces so that a collision occurs with 50% probability. This is very important in the long-term keys. If a (key,nonce) pair is resued then the confidentiality is lost. The 192-bit prevents this. It is an almost never-going-to-happen event for Cryptography.

Is there a significant advantage of using XSalsa20Poly1305?

• The obvious one is the long nonces.
• The other one is the Poly1305 is a better authenticator than the GCM.
• It has very good CPU performance thanks to ARX design, beats AES in raw CPU and even it can compete AES-NI.

OpenSSL comparisons (ChaCha not Salsa);

Also, note that in the paper Bernstein provided security proof; if Salsa20 is secure then XSalsa, too.

It is proven that 15 rounds of the Salsa20 is secure against differential attacks.

• 2013, Mouha and Preneel, Towards Finding Optimal Differential Characteristics for ARX: Application to Salsa20

Note that there is a new variant of the Salsa family; the ChaCha family. ChaCha family is aimed to increase the diffusion per round with almost the same speed. ChaCha family is adapted more than the Salsa family, TLS 1.3 uses ChaCha20-Pol1305.

ChaCha20 has also XChaCha20-Poly1305 (ietf draft) that uses the same 192-bit nonce sizes. It is preferable to XSalsa20-Poly1305. Note that the ChaCha family is less studied than the Salsa family due to the fact that Salsa is represented in eSTREAM project.

Prefer XChaCha20-Poly1305 if you can.

Note that Authenticated encryption is a must on transmit, it is advisable for data on the rest.