Update anchors, line breaks, tootctl options (#745)

* update anchors

* remove extraneous anchors

* fix line breaks

* wrap tootctl tokens in code blocks

* change anchors to hugo format

* fix mistaken search-and-replace

* fix mistaken search-and-replace

content/en/admin/backups.md

@@ -1,16 +1,15 @@
 ---
 title: Backing up your server
+description: Setting up regular backups (optional, but not really)
 menu:
   docs:
     weight: 80
     parent: admin
 ---
 
-## Setting up regular backups \(optional, but not really\) <a id="setting-up-regular-backups-optional-but-not-really"></a>
-
 For any real-world use, you should make sure to regularly backup your Mastodon server.
 
-### Overview <a id="overview"></a>
+## Overview {#overview}
 
 Things that need to be backed up in order of importance:
 
@@ -19,7 +18,7 @@ Things that need to be backed up in order of importance:
 3. User-uploaded files
 4. Redis database
 
-### Failure modes <a id="failure-modes"></a>
+## Failure modes {#failure}
 
 There are two failure types that people in general may guard for: The failure of the hardware, such as data corruption on the disk; and human and software error, such as wrongful deletion of particular piece of data. In this documentation, only the former type is considered.
 
@@ -33,23 +32,23 @@ Losing the Redis database is almost harmless: The only irrecoverable data will b
 
 The best backups are so-called off-site backups, i.e. ones that are not stored on the same machine as Mastodon itself. If the server you are hosted on goes on fire and the hard disk drive explodes, backups stored on that same hard drive won’t be of much use.
 
-### Backing up application secrets <a id="backing-up-application-secrets"></a>
+## Backing up application secrets {#env}
 
 Application secrets are the easiest to backup, since they never change. You only need to store `.env.production` somewhere safe.
 
-### Backing up PostgreSQL <a id="backing-up-postgresql"></a>
+## Backing up PostgreSQL {#postgresql}
 
 PostgreSQL is at risk of data corruption from power cuts, hard disk drive failure, and botched schema migrations. For that reason, occassionally making a backup with `pg_dump` or `pg_dumpall` is recommended.
 
 For high-availability setups, it is possible to use hot streaming replication to have a second PostgreSQL server with always up-to-date data, ready to be switched over to if the other server goes down.
 
-### Backing up user-uploaded files <a id="backing-up-user-uploaded-files"></a>
+## Backing up user-uploaded files {#media}
 
 If you are using an external object storage provider such as Amazon S3, Google Cloud or Wasabi, then you don’t need to worry about backing those up. The respective companies are responsible for handling hardware failures.
 
 If you are using local file storage, then it’s up to you to make copies of the sizeable `public/system` directory, where uploaded files are stored by default.
 
-### Backing up Redis <a id="backing-up-redis"></a>
+## Backing up Redis {#redis}
 
 Backing up Redis is easy. Redis regularly writes to `/var/lib/redis/dump.rdb` which is the only file you need to make a copy of.