DEL HTML anchors from posts as they are going to be added automaticly with new ssg

items/2023-01-10_long_backup-guide.md

@@ -9,7 +9,7 @@ I've tried to keep this guide accessible for personal and corporate backups.
 
 The main goal of backups is data loss prevention. There are numerous risks that could cause data loss, and we try to prevent them with a backup strategy that fits our needs. I'll go into more detail in the next section.
 
-#### Risks <a href="#risks" id="risks">#</a>
+#### Risks 
 
 The following risks exist for data in production and for your backups! - There are many more, but this section will give you a feeling of the most common risks.
 
@@ -40,7 +40,7 @@ Some 'disasters' affect only a single hard drive, some devices, or the whole net
 
 **Side note**: Backups do not prevent those risks, but minimize the damage and help to recover from them.
 
-#### RAID/snapshots are no backups! <a href="#raid-is-not-a-backup" id="raid-is-not-a-backup">#</a>
+#### RAID/snapshots are no backups! 
 
 **RAID** - *redundant array of independent disks* - is a method to either increase the performance, the availability and resiliency, or both. Misconfigured, it can even cause more damage; for example, a RAID0 can make the whole array useless after a disk failure. Don't let me get started with broken hardware RAID controllers or RAID expansions.
 
@@ -54,7 +54,7 @@ Snapshots, therefore, should not be considered a valid backup!
 
 Both solutions can be part of your backup strategy but can't replace a regular backup.
 
-# Determine what to backup and why <a href="#what-to-backup" id="what-to-backup">#</a>
+# Determine what to backup and why 
 
 What and why you backup specific files highly depend on your needs. It is helpful to have an inventory of critical infrastructure to determine what to backup. 
 
@@ -68,7 +68,7 @@ Some other category is the frequency with which the data gets updated. An exampl
 
 Remember to provide some kind of backup solution for devices like laptops and smartphones. 
 
-# Data Retention Policy <a href="#data-retention-policy" id="data-retention-policy">#</a>
+# Data Retention Policy 
 
 With the Data Retention Policy, we try to specify how long to retain certain data. There are various factors you should consider: usefulness, compliance, laws, and so on.
 
@@ -76,7 +76,7 @@ Some system data, like old configuration files, can be deleted after a short tim
 
 **Side note**: as mentioned before, this highly depends on your setup, and speaking to the relevant departments is recommended. 
     
-#### Backup/data deletion <a href="#data-deletion" id="data-deletion">#</a>
+#### Backup/data deletion 
 
 Deleting data or backups seems not worth talking about, but data can be easily recovered if it is not done correctly.
 
@@ -86,7 +86,7 @@ Some laws/compliances require you to destroy data in a certain way. To make sure
 
 To be secure, store your backups encrypted in the first place.
 
-# Decide the backup frequency <a href="#data-frequency" id="data-frequency">#</a>
+# Decide the backup frequency 
 
 The frequency of your backups will determine the impact of a disaster in terms of data loss. The more frequently you do backups; the less is data loss in case a disaster occurs. There are two metrics you could consider: **RTO** and **RPO**.
 
@@ -106,7 +106,7 @@ With the RTO we want to determine the maximum tolerable amount of down time afte
 Like the RPO, every system can have its own RTO, and the RTO ends when data is recovered and it is up again.
 
 
-# Document everything <a href="#documentaion" id="documentaion">#</a>
+# Document everything 
 
 As in so many areas; documentation is king. 
 
@@ -123,11 +123,11 @@ Something that should not be overlooked is a **contact list**. What people must
 Don't forget to **store** the documents **securely, but accessible**. Detached from the backup, like printed out, or on a USB stick in a safe.
 
 
-# How to backup! <a href="#how-to-backup" id="how-to-backup">#</a>
+# How to backup! 
 
 As mentioned before, there is no perfect solution, and you must find a backup strategy that works for you. Like everything, it has pros and cons, and you have to decide what works for you. I'll show you some points to consider.
 
-#### 3-2-1 rule <a href="#3-2-1-rule" id="3-2-1-rule">#</a>
+#### 3-2-1 rule 
 
 I want to start with the well-known **3-2-1 rule**:
 : have **3** copies of your data
@@ -136,7 +136,7 @@ I want to start with the well-known **3-2-1 rule**:
 
 The 3-2-1 rules should be considered the bare minimum of every backup strategy. I'll go into more detail in the following points.
 
-#### Have multiple copies of your data <a href="#multiple-copies" id="multiple-copies">#</a>
+#### Have multiple copies of your data 
 
 Who would have known? But just to be sure, consider some points.
 
@@ -144,7 +144,7 @@ Sounds obvious, but avoid storing backups of a system on the same system or stor
 
 Spread copies over multiple mediums and use different methods. Every storage medium/method has its risks, and having copies on multiple mediums increases the resiliency overall.
 
-#### Locations <a href="#locations" id="locations">#</a>
+#### Locations 
 
 Make use of **different locations**. 
 
@@ -156,13 +156,13 @@ Some examples would be:
 Just make sure that you can access the offsite backups whenever you can and add this factor into your strategy.
 
 
-#### Encrypt backup storage and transfer <a href="#encryption" id="encryption">#</a>
+#### Encrypt backup storage and transfer 
 
 This is especially important for offsite backups but can be necessary for local backups too. Make sure that you use a **secure encryption method**, **use a secure password/password** or another method, and **encrypt the transit and storage**! Still will protect the integrity of your data from tampering of a third party, and makes your data worthless in case a third party gets access to the backups.
 
 **Important**: **Do not lose the keys!** - Backup your decryption method, store it securely (not with your backups), and ensure that the decryption key is **accessible in any disaster scenario**!
 
-#### Think about the right tools <a href="#right-tools" id="right-tools">#</a>
+#### Think about the right tools 
 
 Could you access your backups in 10 years? Is the technology still around? Is the de-/encrpytion service provider still in business?
 
@@ -172,11 +172,11 @@ It is recommended to use **well-known open-source services**. Niche and propriet
 
 Try to **automate** as much as possible, so backups won't be forgotten, and make sure that the **backup process doesn't disrupt** the daily business.
 
-#### Store backups immutable/read-only <a href="#immutable-storage" id="immutable-storage">#</a>
+#### Store backups immutable/read-only 
 
 Keeping the backup storage immutable prevents anyone from tampering with the backups and increases the data integrity. There are cases in which you have to delete certain data from backups, but in general, it is recommended to store them immutable.
 
-#### Choose the right storage medium <a href="#storage-medium" id="storage-medium">#</a>
+#### Choose the right storage medium 
 
 There are multiple factors that will play into the choice of a storage medium. 
 
@@ -200,18 +200,18 @@ Things to consider:
 
 The choice of medium will affect the recovery process and speed and is overall important.
 
-#### Have the recovery process in mind <a href="#recovery-process" id="recovery-process">#</a>
+#### Have the recovery process in mind 
 
 Think backward from a recovery standpoint. You have to recover system 'A' and what else must be up to get system 'A'
 running again? This might give you another perspective.
 
-#### Avoid single point of failures <a href="#single-point-of-failure" id="single-point-of-failure">#</a>
+#### Avoid single point of failures 
 
 ![explanation-single-point](/images/blog/backup-single-point.png)
 
 There are plenty of examples: single backup server, a single person with access to backups, single internet connection with cloud backups only, and so on.
 
-#### Use different backup types <a href="#backup-types" id="backup-types">#</a>
+#### Use different backup types 
 
 I won't go into detail, but the main goal is to save time and storage. 
 
@@ -226,13 +226,13 @@ I won't go into detail, but the main goal is to save time and storage.
 **Incremental backups** store the changes from the last full backup or incremental backup.
 
 
-#### Restrict and secure access to the backups <a href="#backup-access" id="backup-access">#</a>
+#### Restrict and secure access to the backups 
 
 Backups should only be accessible by trusted parties. Admins only, separate network, MFA, and other security measurements are recommended. The goal is further to limit the risks of tampering, theft or deletion.
 
 **Side note**: make sure that you do not lock yourself out. This is critical and should be tested regularly.
 
-# Trust but verify <a href="#verification" id="verification">#</a>
+# Trust but verify 
 
 ![explanation-monitoring](/images/blog/backup-monitoring.png)
 
@@ -245,7 +245,7 @@ Things to look for: failed backup jobs, unusual activities, access attempts, and
 Let third party/experts **audit** your backup strategy. It is easy to overlook certain things, and it can be beneficial to have another perspective.
 
 
-# Test recoverability regularly <a href="#test-recover-process" id="test-recover-process">#</a>
+# Test recoverability regularly 
 
 ![explanation-recovery](/images/blog/backup-recovery.png)