参考文档：

Controller backups
Client
Juju Tricks
Restoring from a backup

控制器的备份使人们可以保存（并在以后重新建立）控制器的配置和状态。它不会影响后备云上的工作负载实例。也就是说，如果此类实例直接在云中终止，则控制器还原将无法重新创建该实例。

此页面将涵盖以下主题：

• 创建备份
• 管理备份
• 高可用性注意事项

有一个单独的页面，描述了如何从备份中还原。

juju控制器

Juju提供了用于在发生故障或控制器不再存在时恢复控制器的命令。

当前状态保存在“控制器”模型中。因此，所有备份命令都需要明确地在该模型内运行或通过确保当前模型为“控制器”模型来进行操作。在下面提供的示例中，控制器名称和型号名称均明确表示（例如-m aws：controller）。由于数据备份的微妙特性，强烈建议使用此方法

创建备份

create-backup命令用于创建备份。它是通过生成存档并将其作为“ tar.gz”文件（本地备份）下载到Juju客户端系统来实现的。如果使用
--keep-copy选项，则存档的副本也将保留在控制器上（远程备份）。借助--no-download选项，可以防止本地备份，但是由于存档必须保存在某处，因此该选项意味着--keep-copy。

备份的名称由创建时间（以UTC表示）和唯一标识符组成。

以下示例假定存在以下控制器（输出到juju controllers）：

Controller  Model    User   Access     Cloud/Region         Models  Machines    HA  Version
aws         default  admin  superuser  aws/us-east-1             2         1  none  2.3.7  
lxd*        default  admin  superuser  localhost/localhost       2         1  none  2.3.7

要创建“ aws”控制器的备份，请执行以下操作：

juju create-backup -m aws:controller

样本输出类似下面：
20180515-191942.7e45250b-637a-4dc9-8389-c6aa70100cd6
downloading to juju-backup-20180515-191942.tar.gz

从档案名称中，我们看到备份是在2018年5月15日UTC进行的。

存档文件名不包含关联的控制器名称。因此，从多个控制器进行归档时应格外小心。要指定自定义名称，请使用--filename选项。该选项不会影响远程归档名称。

要在使用自定义文件名并添加可选注释的同时创建“ lxd”控制器的备份，请执行以下操作：

juju create-backup -m lxd:controller --filename juju-backup-lxd-20180515-193724.tar.gz "fresh lxd controller"

可选注释通过下面详细介绍的show-backup命令公开。

无论云类型如何，新的（空）环境的备份大小约为83 MiB。

管理备份

以下命令可用于管理备份（除还原外）：

• backups
• show-backup
• download-backup
• upload-backup
• remove-backup

juju backups

backups命令显示给定控制器的所有远程备份的名称。例如，要查看“ lxd”控制器的所有远程存储备份，请执行以下操作：

juju backups -m lxd:controller

输出类似下面：

20180515-193724.9c6a3650-2957-489a-8f0c-6c3b5ce2e055
20180515-195557.9c6a3650-2957-489a-8f0c-6c3b5ce2e055

juju show-backup

show-backup命令提供特定远程备份的元数据记录（通过backups命令标识）。例如，要查询存储在“ lxd”控制器上的备份，请执行以下操作：

juju show-backup -m lxd:controller 20180515-195557.9c6a3650-2957-489a-8f0c-6c3b5ce2e055

输出类似如下：

backup ID:       "20180515-193724.9c6a3650-2957-489a-8f0c-6c3b5ce2e055"
checksum:        "pmxx7bCwtZVV+KM48YKz5w6Boc0="
checksum format: "SHA-1, base64 encoded"
size (B):        58605244
stored:          2018-05-15 19:40:28 +0000 UTC
started:         2018-05-15 19:37:24 +0000 UTC
finished:        2018-05-15 19:37:41 +0000 UTC
notes:           "fresh lxd controller"
model ID:        "9c6a3650-2957-489a-8f0c-6c3b5ce2e055"
machine ID:      "0"
created on host: "juju-e2e055-0"
juju version:    2.3.7

开始时间是各种时间戳中最相关的。它指的是创建备份的时间。

juju download-backup

download-backup命令下载特定的远程备份（同样，通过backups命令标识）。在这里，我们下载了存储在“ aws”控制器中的备份：

juju download-backup -m aws:controller 20180515-191942.7e45250b-637a-4dc9-8389-c6aa70100cd6

juju upload-backup

upload-backup命令将特定的本地备份上传到控制器。例如：

juju upload-backup -m lxd:controller juju-backup-20180515-193724.tar.gz

无法上传与远程存储的备份等效的文件。该过程将被取消，并且将显示一条错误消息。

juju remove-backup

remove-backup命令从控制器中删除特定的远程备份。例如：

juju remove-backup -m aws:controller 20180515-191942.7e45250b-637a-4dc9-8389-c6aa70100cd6

要清理任何可能的远程备份，可以使用--keep-latest选项。此选项指示Juju删除所有远程备份，但最新创建的备份除外：

juju remove-backup -m aws:controller --keep-latest

从备份还原

要将环境的状态还原到以前的时间，请使用独立的juju-restore工具。

以前使用juju restore-backup命令，但是从Juju 2.9开始，该命令已弃用，而应使用juju-restore代替。

高可用性注意事项

尽管Controller高可用性使Juju基础架构更加健壮（并且负载均衡），但它不应取代对数据备份的需求。但是，这样做确实不太可能从备份还原，因为只要一个控制器群集成员保持运行状态，就可以通过enable-ha命令替换其他成员。因此，仅在所有控制器都发生故障时，才有必要在高可用性方案中进行还原。但是，如果将还原应用于具有活动成员的群集，则所有可访问的控制器自然会覆盖其数据。

由于完全群集故障而还原

在所有控制器无响应的情况下，应采取以下步骤：

• 卸下控制器
• 创建一个原始控制器
• 执行数据还原
• 启用高可用性

为了演示这一点，请考虑一个初始的基于AWS的名为“ aws-ha3-1”的控制器，其中包含三个集群成员。新的控制器将称为“ aws-ha3-2”：

juju kill-controller aws-ha3-1
juju bootstrap aws aws-ha3-2
# use juju-restore to perform the data restore
juju enable-ha -m aws-ha3-2:controller -n 3

实际操作步骤：

第一种方式：备份客户端方式

此页面涵盖了可以以管理员用户或普通用户身份应用于Juju客户端（用于管理Juju的软件）的各种操作。

涵盖以下主题：

• 客户目录
• 客户端备份
• 客户端升级

有关客户端的完整定义，请参见“概念”页面。

客户目录

Juju客户端目录在Ubuntu上位于 ~/.local/share/juju
除了您可以重新创建的凭据YAML文件之类的内容之外，该目录还包含Juju的SSH密钥等唯一文件，这些文件对于连接到Juju计算机是必不可少的。此位置也可能是charms或模型所需资源的所在地。

在Microsoft Windows上，该目录位于其他位置（通常为 C:\Users{username}\AppData\Roaming\Juju）

客户端备份

客户端的备份使用户可以重新获得对控制器和相关云环境的管理控制。

本节将涵盖以下主题：

• 创建备份
• 从备份还原

数据备份也可以通过Juju控制器进行。请参阅控制器备份页面以获取指导。

创建备份

复制客户端目录足以备份客户端。这通常是通过备份软件完成的，该备份软件将数据压缩为单个文件（存档）。在Linux / Ubuntu系统上，tar程序是常见的选择：

cd ~
tar -cpzf juju-client-$(date "+%Y%m%d-%H%M%S").tar.gz .local/share/juju

Microsoft Windows，任何本机Windows备份工具都可以。

上面的调用在生成的归档文件的文件名中嵌入了一个时间戳，这对于了解何时进行备份很有用。当然，您可以随心所欲地对其进行命名。

通常应将归档文件转移到另一个系统（或至少转移到另一个物理驱动器）以进行安全保存。

从备份还原

还原客户端设置很简单，只需提取先前创建的备份即可。对于Ubuntu：

cd ~
tar -xzf juju-yymmdd-hhmmss.tar.gz

此命令将提取存档的内容并覆盖Juju目录中的所有现有文件。确保这是您想要的。

客户端升级

客户端软件由操作系统的程序包管理系统管理。在Ubuntu上，传统上是APT：

sudo apt update
sudo apt install juju

如果Juju是通过快照安装的，则无需采取任何措施，因为默认情况下快照会自动更新。但是，这是手动更新的方法：

sudo snap refresh juju

可以查询当前的Juju snap版本：

snap info juju

有关更多安装信息以及可用版本的信息，请参见《参考：安装Juju》。

模型也可以升级。请参阅升级模型页面以获取指导

第二种备份方法

转储数据库内容
尽管存在juju create-backup，但是您可以通过登录到控制器并运行以下命令来转储原始Juju数据库：

datestamp=`date +"%Y-%m-%d_%H-%M-%S"`
conf=/var/lib/juju/agents/machine-*/agent.conf
user=`sudo grep tag $conf | cut -d' ' -f2`
password=`sudo grep statepassword $conf | cut -d' ' -f2`
mongodump -h 127.0.0.1:37017 --username $user --password $password --authenticationDatabase admin  --db juju -o mongodump --ssl --sslAllowInvalidCertificates
tar -zcf "juju-mongodump-${datestamp}.tar.gz" mongodump