我在更新时遇到了错误
api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })
请帮我修复它。up/backup-config
restic --cache-dir=/var/restic
backup
/etc
/root
/var/discourse
/opt/backup
–exclude /var/discourse/shared/data/postgres_data
restic --cache-dir=/var/restic forget
–prune --keep-hourly 24 --keep-daily 7 --keep-monthly 3
EOF
chmod +x backup
这些细节会根据 restic 目标的不同而有所差异。并非所有目标都使用 AWS 环境变量，因此请阅读 restic 文档。
```shell
# cat > backup-config <<EOF
### 这些细节取决于你配置的 restic 目标，因此请修改它们
export AWS_ACCESS_KEY_ID=你的访问密钥
export AWS_SECRET_ACCESS_KEY=你的密钥
export RESTIC_PASSWORD_FILE=/root/restic-password
export RESTIC_REPOSITORY=参见 restic 文档
EOF
# {$EDITOR:-nano} /root/restic-password
你需要保存一份 /root/restic-password 中内容的副本，否则你将无法读取备份！请使用你的密码保险箱。
最后，创建一些服务，初始化 restic 存储库，并设置一个计时器以开始备份。
# cat > /etc/systemd/system/backup.service <<EOF
[Unit]
Description=备份到远程目标
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
StandardOutput=file:/var/log/backup.out
StandardError=file:/var/log/backup.err
WorkingDirectory=/var/discourse
ExecStart=/opt/backup/backup
[Install]
WantedBy=multi-user.target
EOF
# cat > /etc/systemd/system/backup.timer <<EOF
[Unit]
Description=定期系统备份
[Timer]
Persistent=true
OnCalendar=00/4:30:00
Unit=backup.service
[Install]
WantedBy=timers.target
EOF
# systemctl daemon-reload
# . /opt/backup/backup-config
# restic init
# /opt/backup/backup
# systemctl enable backup.timer
完成此过程后，你应该能够看到你已经创建了初始备份。
# restic snapshots
我已成功使用这种方式制作的 restic 备份，通过 restic restore 命令将 Discourse 服务器从一个系统迁移到另一个系统。
流式 minio 图像备份
作为 Restic 的替代方案，虽然数据库备份可以存储到 S3，但没有独立于从 S3 提供图像的 S3 图像备份。另一种方法是使用 minio-client 将图像复制到任何类似 S3 的存储。这可以是许多类似 S3 的目标，包括 S3 和 minio，但 不包括 DigitalOcean Spaces，因为它构建在 Ceph 文件系统之上，而 Ceph 文件系统并未以与 S3 相同的方式实现 ListObjectsV2 API。
在 S3 中，创建一个阻止公共访问的存储桶（在 AWS 中，权限 → 阻止公共访问 是正确设置的最简单方法）。
以某种方式安装 minio-client (mc)。这是一种方法。
curl https://dl.min.io/client/mc/release/linux-amd64/mc > /usr/local/bin/mc && chmod +x /usr/local/bin/mc
使用类似以下的命令配置一个名为 backup 的别名来设置 minio-client：
# mc alias set backup https://s3.amazonaws.com ACCESSKEY SECRETKEY --api S3v4
# mc mirror /var/discourse/shared/standalone/uploads backup/UPLOADS-BACKUP-BUCKET
然后创建一个服务 /etc/systemd/system/backup-uploads.service，如下所示：
[Unit]
Description=Discourse 上传文件的近实时远程备份同步
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=600
User=root
ExecStart=/usr/local/bin/mc mirror --overwrite -a --watch /var/discourse/shared/app/uploads backup/UPLOADS-BACKUP-BUCKET
[Install]
WantedBy=multi-user.target
请注意，此处的 UPLOADS-BACKUP-BUCKET 应该是一个与配置 Discourse 上传数据库备份的 s3_backup_bucket 不同的存储桶。另外，请注意，如果你使用标准的多容器部署，路径将是 /var/discourse/shared/web_only/uploads。
# systemctl enable backup-uploads
# systemctl start backup-uploads
# journalctl -fu backup-uploads
上传一个测试图像，确保你看到成功备份原始图像和优化图像的行。在 journalctl 中按 Control-C 将退出跟随模式。
恢复
截至本文撰写时，我从未需要测试此计划。此摘要可能会遗漏一些内容。
- 通常恢复所有备份的文件
- 启动 nginx（现在你的维护页面将显示）
- 使用 /var/discourse/containers 中恢复的文件进行正常的 Discourse 部署
- 如果你没有从备份中恢复，请在 /usr/local/bin/mc 中安装 minio-client
- 如果你没有备份
/root/mc，设置备份别名# mc alias set backup https://s3.amazonaws.com ACCESSKEY SECRETKEY --api S3v4 # mc cp backup/UPLOADS-BACKUP-BUCKET /var/discourse/shared/app/uploads- 恢复最近的数据库备份；我建议你 Restore a backup from the command line
- 只有在你确认站点运行正常后，才按照上述文档重新配置上传备份到 S3。
流式 postgresql 备份
未来，我可能会创建、测试并提供一种配置，以启用使用 连续 WAL 归档 通过 postgresql 中的 archive-command 使用 minio-client 流式传输近乎即时的 Postgres 备份，类似于流式上传备份。
性能监控
至少有两种性能监控方法。
Prometheus 容器
设置 prometheus，如果你在同一个系统上运行它，将 prometheus 日志放在 /var/discourse/shared/prometheus 中。Prometheus 文件可能会变得很大，你不想让它们填满根文件系统；如果你迁移到新的主机系统（无论是升级到更大的 VM 还是安装新操作系统的 VM），你可能也想带上它们。
如果你在 Discourse 系统（或公共互联网上的任何地方）部署 prometheus，请在其前面配置安全。以这种方式安装，一种选择是使用如下 nginx 配置：
location /prometheus/ {
auth_basic "Prometheus";
auth_basic_user_file /etc/nginx/prometheus-htpasswd;
proxy_pass http://localhost:9090/;
}
Sysstat
如果 Prometheus 过于复杂，请考虑使用 sysstat 代替。
dnf install sysstat（或在 debian 及其衍生版本上apt install sysstat）systemctl enable --now sysstatsystemctl enable --now sysstat-collect.timersystemctl enable --now sysstat-summary.timersystemctl edit sysstat-collect.timer并将OnCalendar=*:00/10更改为OnCalendar=*:00/2- 如果 /etc/default/sysstat 存在，将
false更改为true
此后，sar 命令可以告诉你是否偶尔资源不足。
其他资源
这里有一个补充（且更紧凑）的讨论，关于在内部使用 Discourse 作为主要的内部沟通形式。
我在添加 prometheus（占用更多内存）之前进行了配置更改，因此在我更改该设置之前，我可能会先将 prometheus 迁移到该服务器实例之外。
