1 files changed, 4 insertions, 4 deletions
diff --git a/content/entry/back-up-your-data.md b/content/entry/back-up-your-data.md
index 468f63f..088a250 100644
--- a/content/entry/back-up-your-data.md
+++ b/content/entry/back-up-your-data.md
@@ -44,21 +44,21 @@ For one, you have to trust the cloud service's security practices. If they get c
 
 Another risk is that the data is modified either intentionally or by error. Encrypting the data will not prevent it from being modified maliciously. For that, you need authenticated encryption. Also, you may be limited on monthly bandwidth or file storage capacity. If you store a lot of data, that could quickly become expensive.
 
-Using a cloud service provider, you can only access your data at their leasure. Hopefully their system has good uptime. This usually isn't a big problem. But they will also have full control over how you access your data. They might only allow you to access it over a web portal. You'll want to make sure they run a service you can access using only free software such as Nextcloud[3] or Etesync[4]. Preferably, they give you many ways to access it so you aren't locked in to a particular client program.
+Using a cloud service provider, you can only access your data at their leisure. Hopefully their system has good uptime. This usually isn't a big problem. But they will also have full control over how you access your data. They might only allow you to access it over a web portal. You'll want to make sure they run a service you can access using only free software such as Nextcloud[3] or Etesync[4]. Preferably, they give you many ways to access it so you aren't locked in to a particular client program.
 
 # How to Backup?
 Now that I've covered the 5 W's (why, what, when, where, who), I'll cover the most important aspect of backups: How to do them. There is an endless list of software that can help with backups. One good rule is you should always use free software[5] for your backups. Never use proprietary software[6] for any part of the backup process. There's no reason for it and it will compromise your backup security.
 
 ## Offsite Backup
-The first part of the backup process is to decide which data you want to store. Then, you should decide how you want to handle the remote backup. If you use a VPS, you control how you access your data, but all other caveats still apply. On a VPS, you can host your own service for the remote backup. As I said, there are a thousand ways to do this depending on your needs. If you like to keep it barebones, you can run a simple ssh server. If you are hosting a backup for more than just yourself, you may want to use an actual backup platform such as Nextcloud. There are several OS's that are built for the express purpose of backups from FreeNAS[7] to OpenMediaVault[8]. It doesn't really matter which you choose as long as it's meets your needs and runs free software.
+The first part of the backup process is to decide which data you want to store. Then, you should decide how you want to handle the remote backup. If you use a VPS, you control how you access your data, but all other caveats still apply. On a VPS, you can host your own service for the remote backup. As I said, there are a thousand ways to do this depending on your needs. If you like to keep it bare bones, you can run a simple ssh server. If you are hosting a backup for more than just yourself, you may want to use an actual backup platform such as Nextcloud. There are several OS's that are built for the express purpose of backups from FreeNAS[7] to OpenMediaVault[8]. It doesn't really matter which you choose as long as it's meets your needs and runs free software.
 
 ## Encryption
 Once you have your offsite service set up, it's time to perform the backup. The first thing you'll want to do before anything else is encrypt your data. For most people, you'll want to use Veracrypt[9]. It's user friendly and cross-platform. For a guide on how to use Veracrypt, follow the beginner's tutorial[10]. Other encryption programs require using the command-line, decrypting the data to disk before reading it, or only work on GNU/Linux. For those reasons I won't use them in this tutorial. However, if you feel comfortable using LUKS or GPG, go ahead. Just know the trade-offs.
 
-This next step is optional, but I recommend it. Veracrypt does not perform authenticated encryption. Your data is still encrypted, but it could be maliciously changed by an attacker and Veracrypt won't know about it. The best way to prevent this is with an HMAC. On GNU/Linux, you can do this with a single command as long as you have openssl installed. It doesn't seem as easy to perform on other platforms. For your HMAC password, you can reuse your Veracrypt volume password. Copy the resulting HMAC value, then save it to a text file next to your Veracrypt container file. It should also go into your backups. When you retrieve your backups later, you can perform the HMAC operation on the downloaded container file checking that the result matches the value you saved before. This provides you file integrity. At this point, I recommend deleting unencrypted copies of your data on disk since there's no good reason to have them around.
+This next step is optional, but I recommend it. Veracrypt does not perform authenticated encryption. Your data is still encrypted, but it could be maliciously changed by an attacker and Veracrypt won't know about it. The best way to prevent this is with an HMAC. On GNU/Linux, you can do this with a single command as long as you have Openssl installed. It doesn't seem as easy to perform on other platforms. For your HMAC password, you can reuse your Veracrypt volume password. Copy the resulting HMAC value, then save it to a text file next to your Veracrypt container file. It should also go into your backups. When you retrieve your backups later, you can perform the HMAC operation on the downloaded container file checking that the result matches the value you saved before. This provides you file integrity. At this point, I recommend deleting unencrypted copies of your data on disk since there's no good reason to have them around.
 
 ## Finishing Up
-Now your data is finally ready to go into storage. Upload the Veracrypt container file along with the HMAC text file to your remote backup system. Then copy your data onto external media such as a USB flash drive, external hard drive, or SD card. This will serve as your offline backup. You can store your third backup on the same computer you use to access and modify the data, or you can choose a different one so it's not taking up space. That's up to you. Just be sure to have at least 3 copies of your data, one of them at a remote location and one of them air-gapped. You could write a script to do the backups and check the HMAC for you.
+Now your data is finally ready to go into storage. Upload the Veracrypt container file along with the HMAC text file to your remote backup system. Then copy your data onto external media such as a USB flash drive, external hard drive, or SD card. This will serve as your offline backup. You can store your third backup on the same computer you use to access and modify the data, or you can choose a different one so it's not taking up space. That's up to you. Just be sure to have at least 3 copies of your data, one of them at a remote location and one of them air gapped. You could write a script to do the backups and check the HMAC for you.
 
 Finally, you'll want to decide on your backup schedule. To add to your backup, you can simply mount your Veracrypt container and add more files. If you ever run out of space, you can always create a larger container and transfer all your data there. I hope you found this guide useful. I didn't go into as much detail as I could have about remote backup solutions, but I think I covered what needed to be covered.