collective.recipe.backup 5.0.0

简介

此配方主要是一个围绕您Zope构建out中的bin/repozo脚本的包装器。它要求此脚本已经可用。如果这不是这种情况，当您运行其中一个脚本时，您将得到如下错误：bin/repozo: No such file or directory。如果您使用的是plone.recipe.zeoserver，它应该在那里。如果不是这种情况，获取bin/repozo脚本的简单方法是向您的buildout.cfg中添加一个新部分（不要忘记在parts指令中添加它）

[repozo]
recipe = zc.recipe.egg
eggs = ZODB
# or this for an older version:
# eggs = ZODB3
scripts = repozo
dependent-scripts = true

bin/repozo是Zope脚本，用于备份您的Data.fs。查找设置可能是一项繁琐的工作。您还需要选择一个目录来放置备份。此配方为您的常见备份任务提供了合理的默认值。使备份变得容易是很重要的！

• bin/backup创建增量备份。

• bin/restore恢复由备份脚本创建的最后一个备份。

• bin/snapshotbackup创建完整快照备份，与常规备份分开。在网站进行重大更改之前很方便。

• bin/snapshotrestore恢复最新的完整快照备份。

• bin/zipbackup创建zip备份。这会将Data.fs和blob存储压缩在一起，便于将生产数据复制到您的本地计算机，特别是包含许多文件的blob存储。实际上，压缩Data.fs是标准做法，我们不压缩blob存储，因为那里的大多数文件已经是压缩的。但我们确实将blob组合在一个tar存档中。注意：Data.fs和blob存储（或其他存储）不是合并在一个文件中；您需要下载多个文件。使用enable_zipbackup选项启用此脚本。

• bin/ziprestore恢复最新的zip备份。

兼容性

该配方已在Python 2.7、3.6、3.7、3.8、3.9上进行测试。在Plone术语中，它在Plone 4、5和6上运行良好。

请注意，与plone.recipe.zope2instance的集成在Python 3上未进行测试。它会引入太多的依赖项，如Zope和ZODB。

开发

• 代码存储库：https://github.com/collective/collective.recipe.backup

• 问题跟踪器：https://github.com/collective/collective.recipe.backup/issues

• 明显的修正，如修正拼写错误，可以在master上运行。对于较大的更改或如果您不确定，请创建分支或提交拉取请求。

• 代码附带了一个buildout.cfg。请引导构建out并运行创建的bin/test以查看测试是否仍然通过。如果您添加了代码，请尝试添加测试。要为所有支持的Python版本运行测试，请运行tox。

• 此包的长期描述（如PyPI上所示）曾经包含一个包含大量测试代码的大文件，展示了如何使用配方。这变得太大，所以我们将其省略了。如果您想知道某些选项的效果，它可能仍然是好的阅读材料。请参阅src/collective/recipe/backup/tests/*.rst。

• 我们在GitHub Actions上进行了测试：https://github.com/collective/collective.recipe.backup/actions

• 有关问题和评论，请发送至 https://community.plone.org 或发送邮件至 Maurits van Rees。

示例用法

使用此配方最简单的方法是在 buildout.cfg 文件中添加部分，如下所示

[buildout]
parts = backup

[backup]
recipe = collective.recipe.backup

您可以设置许多额外选项，但配方作者喜欢认为他们已经创建了合理的默认值，因此大多数情况下，仅说明配方名称的这行代码就足够了。

运行 buildout 会将 backup、snapshotbackup、zipbackup、restore、snapshotrestore 和 ziprestore 脚本添加到 buildout 的 bin/ 目录。一些默认不会添加，其他可以关闭。

已备份的数据

此配方备份哪些数据？

• 默认位于 var/filestorage/Data.fs 的 Zope 对象数据库 (ZODB) 文件存储。

• 如果您的 buildout 使用它，则 blob 存储自版本 2.0 起被备份，默认位于 var/blobstorage。

未备份的数据

此配方不备份哪些数据？当然，备份所有其他数据，但具体如下

• 存储在 RelStorage 中的数据将不会被备份。（您仍然可以使用此配方来备份文件系统 blob 存储，可能需要使用 only_blobs 选项。）

• 其他存储在 SQL 中的数据，可能通过 SQLAlchemy，将不会备份。

• 它不会备份您整个 buildout 目录。

您的备份是否已备份？

请注意，默认情况下，备份是在 buildout 的 var 目录中创建的，因此如果您意外删除整个 buildout，您也将丢失备份。应该使用 location 选项指定备份位置，例如用户的主目录。您还应该安排将此备份复制到不同的机器/国家/大陆/星球。

备份

调用 bin/backup 会生成一个常规增量 repozo 备份，该备份在 var/backups 中创建 Data.fs 的备份。当您有 blob 存储，它默认备份到 var/blobstoragebackups。

快照

在更新生产服务器之前快速备份是一个好主意。但您可能不想干扰常规的备份制度。为此，bin/snapshotbackup 是很好的选择。它将完整备份放置在默认情况下为 var/snapshotbackups 的位置。

Zip备份

为了快速获取生产数据库的当前状态以便您将其下载到您的开发笔记本电脑，您需要一个完整且压缩的备份。对于 blob 存储，压缩部分很重要，因为您不希望使用 scp 递归地复制所有这些 blob 文件：下载一个 tarball 更快。

您可以使用 bin/zipbackup 脚本来实现这一点。此脚本覆盖了一些设置，忽略 buildout 配置部分中设置的任何内容

• archive_blob 被打开。

• keep 设置为 1 以避免保留大量不必要的备份。

• keep_blob_days 被忽略，因为这是一个完整备份。

脚本在默认情况下将完整备份放置在 var/zipbackups 中，并将 blob 存储的 tarball 放置在 var/blobstoragezips。

此脚本默认不会创建。您可以通过将 enable_zipbackup 选项设置为 true 来启用它。此外，如果 backup_blobs 为 false，则脚本无用处，因此我们不会创建它们，即使您已明确启用它们。

恢复

调用 bin/restore 将恢复最新的常规增量 repozo 备份，如果您有 blob 存储，则还会恢复 blob 存储。

您可以使用 bin/snapshotrestore 恢复最新的快照备份。

您可以使用 bin/ziprestore 恢复 zip 备份。

您还可以恢复到某个特定日期的备份。只需传递一个日期参数。根据 repozo：指定 UTC（而不是本地）时间。格式为 yyyy-mm-dd[-hh[-mm[-ss]]]。例如，简单地说，恢复到 1972 年 12 月 25 日

bin/restore 1972-12-25

或者到那天，在 1 点 2,03 秒后

bin/restore 1972-12-25-01-02-03

从版本 2.3 开始，这也适用于恢复 blob。我们从指定日期的第一个备份或之前恢复目录。（注意，在版本 4.0 之前，我们从指定日期之后的第一个备份中恢复目录，只要您在这之间没有进行数据库打包，那就应该没问题。）

从版本 2.0 开始，恢复脚本在开始恢复之前会要求确认，因为这个命令可能很危险。（“哎呀，我恢复的是实时站点，但我想恢复的是测试站点。”）您需要明确输入“yes”

This will replace the filestorage (Data.fs).
This will replace the blobstorage.
Are you sure? (yes/No)?

请注意，对于大文件存储和 blob 存储，恢复可能需要很长时间。您应该进行一次测试恢复并检查所需时间。秒？分钟？小时？这个时间是否可接受？或者您应该采取其他措施？

已创建脚本的名称

备份部分通常命名为 [backup]，导致 bin/backup 和 bin/snapshotbackup。如果您将部分命名为其他名称，脚本名称也将不同，以及创建的 var/ 目录（自版本 1.2 起如此）

[buildout]
parts = plonebackup

[plonebackup]
recipe = collective.recipe.backup
enable_zipbackup = true

该构建片段将创建这些脚本

bin/plonebackup
bin/plonebackup-full
bin/plonebackup-zip
bin/plonebackup-snapshot
bin/plonebackup-restore
bin/plonebackup-ziprestore
bin/plonebackup-snapshotrestore

支持选项

该配方支持以下选项，默认情况下都不需要。最常更改的是 location 和 blobbackuplocation，因为它们允许您将备份放置在某个系统目录中，如 /var/zopebackups/instancename/ 和 /var/zopebackups/instancename-blobs/。

archive_blob

使用 tar 归档功能。默认为 false。将其设置为 true，则备份/恢复将使用 tar 命令进行。请注意，如果此选项设置为 true，则机器上必须提供 tar 命令。此选项也适用于快照备份/恢复命令。因为这被视为完整备份，所以忽略 keep_blob_days。如果想要压缩存档，请参阅 compress_blob 选项。

alternative_restore_source

您可以从替代源进行恢复。用例：首先备份您的生产站点，然后转到测试或预发布服务器，并在那里恢复生产数据。请参阅 替代恢复源

alternative_restore_sources

alternative_restore_source 的向后兼容拼写。此功能将在版本 7 中不再有效。

backup_blobs

备份 blob 存储。默认在 Python 2.6（Plone 4）及以上版本中为 True，在其他版本中为 False。这要求设置 blob_storage 位置。如果没有设置 blob_storage 位置，并且我们无法通过查找其他构建部分找到它，我们将带错误退出（自版本 2.22 起如此）。如果 backup_blobs 为 false，则 enable_zipbackup 不能为 true，因为在这种情况下 zipbackup 脚本没有用。

blob_storage

存储二进制大对象（blobs）的目录位置。在Plone 4及以上版本中使用，或在Plone 3中使用plone.app.blob时使用。如果备份blobs设置为false，则忽略此选项。默认情况下不设置位置。当使用plone.recipe.zeoserver、plone.recipe.zope2instance或plone.recipe.zope2zeoserver时，我们将检查是否存在blob-storage选项，并将其用作默认值。请注意，我们选择具有此选项的第一个，而不关心共享-blob设置，因此可能存在我们在这里不是最佳决策的角落案例。在这种情况下，请使用此选项来覆盖它。

blob-storage

对首选的blob_storage的另一种拼写，因为plone.recipe.zope2instance将其拼写为blob-storage，而我们使用所有其他选项时都使用下划线。选择其中一个。

blob_timestamps

从版本4.0开始引入。默认值为true（在版本4.2之前为false）。如果为false，则创建blobstorage.0。下一次，我们将它旋转到blobstorage.1并创建一个新的blobstorage.0。使用blob_timestamps = true时，我们将创建不会旋转的稳定目录。它们获得一个时间戳，与ZODB文件存储备份获得的时间戳相同。例如：blobstorage.1972-12-25-01-02-03。或者使用archive_blob = true：blobstorage.1972-12-25-01-02-03.tar。由于文件名是不可预测的，从版本4.1开始，我们创建一个指向最新备份的latest符号链接。由于zipbackup只保留1个备份，这意味着没有混淆哪个文件存储备份属于它，因此blob时间戳不与zipbackup一起使用。

blobbackuplocation

将blob存储备份到的目录。默认为buildout目录中的var/blobstoragebackups。

blobsnapshotlocation

创建blob存储快照的目录。默认为buildout目录中的var/blobstoragesnapshots。

blobziplocation

创建blob存储zip备份的目录。默认为buildout目录中的var/blobstoragezips。

compress_blob

从版本4.0开始引入。默认为false。仅在archive_blob选项为true时使用。打开时，它将压缩存档，结果是一个.tar.gz文件而不是tar文件。在恢复时，我们始终寻找压缩和正常存档。我们以前总是压缩它们，但在大多数情况下，这几乎不会减小大小，而且无论如何都需要很长时间。我见过存档需要15秒，压缩需要额外的45秒。结果是5.0 GB的存档而不是5.1 GB。

datafs

如果Data.fs不在默认的var/filestorage/Data.fs位置，则此选项可以覆盖它。

debug

在极少数情况下，如果您想确切地知道发生了什么，请将debug设置为true以获取配方本身的调试级别日志。如果启用此选项，则也会以--verbose运行repozo。

enable_snapshotrestore

在开发环境中，具有snapshotrestore脚本非常有用，但在生产环境中可能会造成伤害。该脚本将最新快照直接恢复到您的文件存储中，并且它以前无需询问任何问题即可执行此操作（这已更改为需要显式回答yes）。如果您不想有snapshotrestore脚本，请将此选项设置为false。

enable_zipbackup

创建 zipbackup 和 ziprestore 脚本。默认：false。如果 backup_blobs 未开启，这些脚本将始终禁用，因为那时它们没有用。

full

默认情况下，执行增量备份。如果此选项设置为 true，bin/backup 将始终执行完整备份。

incremental_blobs

4.0 版本新增。默认为 false。开启后，将使用 tar 的 --listed-incremental 选项。注意：这仅适用于 GNU 版本的 tar。在 Mac 上，您可能需要使用 brew install gnu-tar 安装它，并根据说明更改 PATH。它将创建元数据或 快照文件，以便第二次调用备份脚本时创建一个包含差异的第二个 tarball。由于某种原因，所有目录最终都会出现在第二个 tarball 中，即使没有任何变化；这可能取决于所使用的文件系统。当 archive_blob 选项为 false 时，此选项将被忽略。此选项 需要 blob_timestamps 选项为 true，因为它需要 tarball 名称是稳定的，而不是旋转。如果您明确将 blob_timestamps 设置为 false，buildout 将因错误退出。注意，当 incremental_blobs 为 true 时，不会创建指向最新备份的 latest 符号链接。对于大型 blob 存储库，恢复可能需要很长时间，因此请务必进行测试。但这在任何情况下都是明智的。本质上，这个功能似乎是在存储空间减少和恢复时间之间进行权衡。

keep

要保留的完整备份数量。默认为 2，这意味着保留当前和上一个完整备份。较旧的备份将被删除，包括它们的增量备份。将其设置为 0 以保留所有备份。

keep_blob_days

要保留的 blob 备份天数。默认为 14，即两周。这仅用于部分（full=False）备份，因此您通常在执行 bin/backup 时使用此选项。此选项是在 2.2 中添加的。对于完整备份（快照），我们只使用 keep 选项。建议将这些值与在 Data.fs 上执行的 zeopack 频率保持同步，根据公式 keep * days_between_zeopacks = keep_blob_days。默认值匹配每七天执行一次 zeopack（2*7=14）。从 4.0 版本开始，除非 only_blobs 为 true，否则此选项将被忽略。相反，我们将删除没有匹配文件存储库备份的 blob 备份。

location

备份存储的位置。默认为 buildout 目录内的 var/backups。

locationprefix

创建所有其他备份和快照文件夹的文件夹位置。默认为 var/。请注意，这不会影响我们查找源文件存储库或 blob 存储库的位置。

only_blobs

仅备份 blob 存储，而不是 Data.fs 文件存储。默认为 false。如果例如您想要创建一个 bin/filestoragebackup 脚本和一个 bin/blobstoragebackup 脚本，可以使用 only_blobs 在一个中，并在另一个中使用 backup_blobs。这可能是一个有用的选项。

post_command

备份完成后要执行的命令。一个用例是取消挂载您之前使用 pre_command 挂载的远程文件系统。有关更多信息，请参阅上面的 pre_command。

pre_command

在开始备份前执行的命令。一个用例是使用NFS或sshfs挂载远程文件系统，并将备份放在那里。任何输出都将被打印。如果您不喜欢这样，您总是可以将输出重定向到其他位置（在Unix上为mycommand > /dev/null）。有关更多信息，请咨询您当地的Unix专家。如果命令执行失败，备份脚本将带错误退出。您可以指定多个命令。

快速

使用repozo的--quick选项。这个选项是在2.19版本中引入到collective.recipe.backup中的，默认值为true。由于repozo默认非快速行为执行的所有校验和，读取的数据量是实际文件存储的三到四倍。使用快速选项，它可能只需几KB。理论上，快速选项不太安全，但它看起来只有在有人编辑仓库中的.dat文件或删除一个.deltafs文件时才会出错。

快速选项只影响创建的bin/backup脚本。它对快照或恢复脚本没有影响。

repozo的帮助信息关于此选项说：“仅通过md5校验和验证最后写入的增量。这显著减少了磁盘I/O，但以不一致性为代价。这是一种确定是否需要完整备份的概率方法。”

rsync_options

向默认的rsync -a命令添加额外选项。默认无额外参数。例如，当您想从一个符号链接目录中恢复备份时，这很有用，在这种情况下，rsync_options = --no-l -k即可解决问题。

rsync_hard_links_on_first_copy

当使用rsync时，第一次备份的blob文件会被复制，然后后续的备份会使用从这次初始复制中建立的硬链接，以节省时间和磁盘空间。启用此选项还可以为初始复制使用硬链接，以进一步减少磁盘使用。这对于ZODB blob是安全的，因为它们不会在原地修改。为了使硬链接成为可能，blob_storage和备份文件夹blobbackuplocation必须在同一分区。

snapshotlocation

存储文件存储快照备份的位置。默认为buildout目录内的var/snapshotbackups。

use_rsync

使用带硬链接的rsync来备份blob。默认为true。但rsync可能并非所有机器上都可用，并且我认为在Windows上硬链接可能不起作用。当您将其设置为false时，我们将回退到简单的复制（实际上是Python中的shutil.copytree）。

ziplocation

存储文件存储zip备份的位置。默认为buildout目录内的var/zipbackups。

使用各种选项的buildout示例片段看起来像这样

[backup]
recipe = collective.recipe.backup
location = ${buildout:directory}/myproject
keep = 2
datafs = subfolder/myproject.fs
full = true
debug = true
snapshotlocation = snap/my
enable_snapshotrestore = true
pre_command = echo 'Can I have a backup?'
post_command =
    echo 'Thanks a lot for the backup.'
    echo 'We are done.'

目录或文件中的路径可以使用相对路径（../），并且会展开~（主目录）和$BACKUP-样式的环境变量。

Cron作业集成

bin/backup 的确是理想的cronjob替代整个 bin/repozo .... 行。但你不想得到“INFO”级别的日志记录，因为你在邮箱里也会得到这些。在你的cronjob中，只需添加 -q 或 --quiet，然后 bin/backup 就会保持安静，除非有问题。如果buildout中设置了true，此选项会忽略调试变量。

说到cron任务？如果你想在你的buildout中处理cron任务，请查看 zc.recipe.usercrontab。例如

[backupcronjob]
recipe = z3c.recipe.usercrontab
times = 0 12 * * *
command = ${buildout:directory}/bin/backup

块存储

新增于版本2.0。

我们可以备份blob存储。Plone 4使用blob存储在文件系统上存储文件（二进制大对象）。在Plone 3中这是可选的。当使用时，当然应该备份。您必须指定Plone（或Zope）存储blob的源blob_storage目录。如前所述，如果我们没有明确设置它，我们将尝试从其他部分获取位置，例如 plone.recipe.zope2instance 脚本

[buildout]
parts = instance backup

[instance]
recipe = plone.recipe.zope2instance
user = admin:admin
blob-storage = ${buildout:directory}/var/somewhere

[backup]
recipe = collective.recipe.backup

如果需要，我们可以告诉buildout我们只想备份blob，或者明确表示不备份blob。使用 backup_blobs 和 only_blobs 选项指定此操作可能非常有用，如果您想将此分成几个脚本

[buildout]
newest = false
parts = filebackup blobbackup

[filebackup]
recipe = collective.recipe.backup
backup_blobs = false

[blobbackup]
recipe = collective.recipe.backup
blob_storage = ${buildout:directory}/var/blobstorage
only_blobs = true

在这个设置下，bin/filebackup 现在只备份文件存储，而 bin/blobbackup 只备份blob存储。

新功能：在版本4.0中，您可能想指定 blob_timestamps = true。然后我们创建不进行轮换的稳定目录。例如：blobstorage.1972-12-25-01-02-03 而不是 blobstorage.0。

rsync

默认情况下，我们使用 rsync 来创建备份。我们使用此工具创建硬链接，以节省磁盘空间并获得增量备份。这可能需要一个类Unix（Linux、Mac OS X）操作系统。它基于Mike Rubel的这篇文章：http://www.mikerubel.org/computers/rsync_snapshots/

我们尚未在Windows上尝试。欢迎提供报告，但最好是在备份部分设置 use_rsync = false 选项。然后我们只需简单地复制blob存储目录。

备选恢复源

新增于版本2.17。在版本5中更改：仅支持一个源。

您可以从备用源进行恢复。用例：首先备份您的生产站点，然后转到测试或预发布服务器并恢复那里的生产数据。

在 alternative_restore_source 选项中，您可以使用以下语法定义不同的文件存储和blob存储备份源目录

alternative_restore_source =
    storagename datafs1_backup [blobdir1_backup]

存储名称必须是 Data（或 1）对于标准的 Data.fs 和可选的blob存储。

结果是 bin/altrestore 脚本。

这将适用于具有单个文件存储和blob存储的标准buildout

[backup]
recipe = collective.recipe.backup
alternative_restore_source =
    Data /path/to/production/var/backups /path/to/production/var/blobstoragebackups

上述配置使用 repozo 从 /path/to/production/var/backups 存储库将Data.fs恢复到标准的 var/filestorage/Data.fs 位置。它将最近的blob存储备份从 /path/to/production/var/blobstoragebackups/ 复制到标准的 var/blobstorage 位置。

支持像正常恢复脚本一样使用特定日期调用脚本

bin/altrestore 2000-12-31-23-59

如果备用源不匹配标准文件存储和blob存储，则recipe将失败。例如，当 alternative_restore_source 缺少 Data 键时，当它有一个额外的键时，当一个键没有路径时，当一个键有额外的或缺少的blob存储时，您会得到错误。

在安装配方过程中，即在执行bin/buildout时，它不会检查源是否存在：您可能在不同服务器上拥有生产备份，需要设置远程共享目录，或者您需要手动复制数据。

请注意，脚本考虑了archive_blob和use_rsync选项。因此，如果替代恢复源包含使用archive_blob = true创建的blob备份，您需要一个也使用此设置的altrestore脚本。

赞助

collective.recipe.backup的工作得以由根特大学（或UGent）提供支持。请参阅https://www.ugent.be。根特大学是前100名大学之一，也是比利时的主要大学之一。

5.0.0 (2023-06-12)

错误修复

• 最终版本，自上一个alpha版本以来没有变化。[maurits]

5.0.0a3 (2023-03-15)

重大更改

• 移除了additional_filestorages选项。移除了在alternative_restore_sources中对多个存储的支持：只支持标准单一文件存储加上blob存储。将alternative_restore_sources重命名为alternative_restore_source，暂时保留旧别名。[maurits] (问题 #64)

• 移除了gzip选项。从现在起，我们始终使用gzip选项调用repozio，您无法再关闭此选项。[maurits] (问题 #67)

• 移除了选项gzip_blob。这是一个向后兼容的别名，用于archive_blob。如果您想创建tar存档，现在应该使用它。另外，如果您确实想压缩存档，请使用compress_blob选项。[maurits] (问题 #68)

• 移除了选项quick。从现在起，我们始终为常规备份调用repozio的quick选项，您无法再关闭此选项。对于完整备份（快照备份和zip备份），不使用quick选项。[maurits] (问题 #69)

错误修复

• 废弃设置blob_timestamps为false。请参阅问题 65。[maurits] (问题 #65)

5.0.0a2 (2023-02-01)

错误修复

• 为版本5.0.0a1添加缺少的变更日志条目。[maurits]

5.0.0a1 (2022-11-08)

重大更改

• 不支持Python 2.7-3.7，添加对3.10的支持。[maurits] (问题 #62)

• 不再支持enable_fullbackup选项和fullbackup脚本。在执行zeopack之后，第一次调用bin/backup会自动进行完整备份。如果您仍然需要此类脚本，请查看bin/snapshotbackup脚本或使用full选项，可选地在一个第二个buildout部分中使用。[maurits] (问题 #66)

新功能

• 添加了一个选项，用于第一个备份副本使用硬链接[ale-rt] (问题 #57)

• 支持Python 3.11。[maurits] （问题 #311）

错误修复

• 删除代码分析，添加其他质量检查：isort、black、flake8。[maurits] （问题 #63）

4.2.0 (2021-08-30)

新功能

• 将 blob_timestamps 的默认值更改为 true。我们可能会在版本 5 中完全移除之前的行为（创建 blobstorage.0、blobstorage.1 等）。[maurits] （问题 #61）

错误修复

• 将测试基础设施切换到 GitHub Actions 和 tox。也测试 Python 3.8 和 3.9。[ale-rt, maurits] （问题 #58）

• 修复使用选项 blob_timestamps 和 no_rsync 时的 latest 符号链接。之前它指向例如 blobstorage.2021-01-02-03-04-05/blobstorage 而不是它上面的目录。[maurits] （问题 #61）

• 在创建 zipbackup 时，不要创建 blob 时间戳。我们始终只保留一个 zipbackup，因此不需要时间戳来确定它属于哪个文件存储备份。[maurits] （问题 #61）

4.1.1 (2019-10-07)

错误修复

• 使用时间戳时，使用正确的文件存储备份位置作为快照和 zip 备份的 blob 时间戳。[maurits] （问题 #55）

4.1.0 (2019-04-10)

新功能

• 创建指向最新时间戳 blobstorage 备份的符号链接。当 blob_timestamps 为 false 时，blobstorage.0 是一个稳定的文件名，但使用 blob_timestamps true 时，这样的稳定名称缺失。[maurits] （问题 #48）

• 删除对 Python 2.6 的官方支持，添加 Python 3.7 支持。没有代码更改，但我们不再测试 2.6。[maurits] （问题 #49）

错误修复

• 在测试 buildout 中更新了包版本。根据 flake8 和 black 提高了代码质量。[maurits] （问题 #49）

• 删除了已禁用的 sitepackage_safe_scripts 支持。[maurits] （问题 #51）

4.0.1 (2018-04-19)

错误修复

• 使用 archive_blob true 时，仍然允许恢复非存档。我们更喜欢存档，但如果找不到合适的存档，我们会寻找非存档。[maurits] （问题 #44）

• 排序 os.listdir，以提高在 Mac 上的性能。[maurits] （问题 #45）

4.0 (2017-12-22)

• 更新了说明文件并添加了赞助说明。[maurits]

4.0b5 (2017-11-17)

• 添加了 incremental_blobs 选项。此选项创建与之前 blob 备份相比仅包含更改的 tarball。当 archive_blob 选项为 false 时，此选项被忽略。[maurits]

• 提高了代码质量，降低了复杂性。[maurits]

• 重构了主要功能，以减少代码重复。普通、完整、快照和 zip 备份几乎具有相同的代码。这使得添加新选项变得困难。[maurits]

4.0b4 (2017-08-18)

• 从现在起在 Travis 上测试 Python 3.6（以及 2.6 和 2.7）。[maurits]

• 在 Python 3 上忽略 zope2instance recipe 集成测试。它们需要一个兼容的 mailinglogger 包。参见 问题 #31。[maurits]

• 测试：使用更干净的方式检查 mock repozo 输出。在测试之间共享此设置。这使得输出顺序在 Python 2 和 3 上相同。参见 问题 #31。[maurits]

4.0b3 (2017-07-05)

• 添加了基本的 Python 3 支持。我们尚未用其进行测试，但您不应再得到 NameError 了。参见 问题 #31。[maurits]

4.0b2 (2017-06-26)

• 默认情况下不再创建fullbackup脚本。您仍然可以通过将enable_fullbackup设置为true来启用它。[maurits]

• 如果没有明确的blob-storage选项，则默认为var/blobstorage。考虑从zeoserver/client配方中获取的var选项。修复了问题#27。[maurits]

• 当blob_storage以斜杠结尾时，不要创建隐藏的备份.0。修复了问题#26。[maurits]

4.0b1 (2017-05-31)

• 使自定义备份位置相对于locationprefix选项或var目录。到目前为止，locationprefix选项仅在您未设置自定义位置时使用。自定义位置将相对于buildout目录。现在它们相对于locationprefix选项，var目录作为默认值。因此，如果您使用相对路径，您的备份可能会出现在不同的路径上。绝对路径不受影响：它们忽略locationprefix。[maurits]

• 当日志级别为DEBUG时，在日志中显示时间戳。[maurits]

• 添加了compress_blob选项。默认为false。仅在archive_blob选项为true时使用。开启时，它将压缩存档，生成一个.tar.gz文件而不是一个tar文件。在恢复时，我们总是寻找压缩和正常存档。我们过去总是压缩它们，但在大多数情况下，这几乎不会减小大小，而且无论如何都要花费很长时间。我见过归档需要15秒，压缩需要额外的45秒。结果是5.0GB的存档，而不是5.1GB。[maurits]

• 将gzip_blob选项重命名为archive_blob。保留了旧名称作为向后兼容的别名。这为创建不压缩的存档留出了空间。[maurits]

• 自动删除没有对应filestorage备份的旧blob备份。我们比较最旧filestorage备份的时间戳与blob备份的时间戳。这可能是一个名称，如果您使用blob_timestamps = true，或者blob备份的修改日期。这意味着keep_blob_days选项被忽略，除非您使用only_blobs = true。[maurits]

• 当备份blobstorage时，使用最新filestorage备份的时间戳。如果已存在同名blob备份，则表示没有数据库更改，因此我们不进行备份。这仅在您使用新的blob_timestamps = true选项时执行。[maurits]

• 当恢复到特定日期时，查找指定日期之前或等于指定日期的第一个blob备份。否则失败。repozo脚本也这样做。我们过去选择指定日期之后的第一个blob备份，因为我们假设用户会指定在filestorage备份中的确切日期。请注意，filestorage和blobstorage备份的时间戳可能相差几秒，除非您使用blob_timestamps == true选项。在新情况下，用户应选择blob备份的日期或稍晚一些。[maurits]

• 添加了 blob_timestamps 选项。默认值为 false。默认情况下，我们创建 blobstorage.0。下一次，我们将它旋转到 blobstorage.1 并创建新的 blobstorage.0。使用 blob_timestamps = true 时，我们将创建不旋转的稳定目录。它们会获得一个时间戳，与 ZODB 文件存储备份相同的时戳。例如：blobstorage.1972-12-25-01-02-03。[maurits]

• 在恢复时，首先运行所有文件存储和 blob 存储的检查。当其中一个备份丢失时，我们以错误退出。这可以避免恢复文件存储后，由于 blob 存储备份丢失而遇到麻烦。[maurits]

3.1 (2017-02-24)

• 添加 locationprefix 选项来配置一个文件夹，其中将创建所有其他备份和快照文件夹。[erral]

• 仅兼容 Python 2.6 和 2.7。[maurits]

• 更新测试 buildout 以使用最新版本。[maurits]

3.0.0 (2015-12-31)

• 重构了此食谱的 init 和 install 方法。在 init 阶段，我们正在读取 buildout 配置，但在此阶段配置仍在构建。因此，可能会出现差异，尤其是在部分执行顺序方面。这并不好。大多数代码现在已从 init 移动到 install（和 update）方法。这有更少可能的问题。缺点：一些配置错误会在稍后捕获。[maurits]

• 从 buildout 部分读取 zeo-var、var、file-storage。根据此更新默认备份和数据.fs 位置。[maurits]

2.22 (2015-12-30)

• 不接受 backup_blobs false 和 enable_zipbackup true。没有 blob，zipbackup 脚本是无用的。[maurits]

• 在 Python 2.6（Plone 4）及更高版本上设置默认 backup_blobs 为 true。否则为 false。如果找不到 blob_storage，我们将以错误退出。[maurits]

• 接受 true、yes、on、1 作为真值，无论大小写或混合大小写。将 buildout 选项中的所有其他值视为假。[maurits]

• 即使它们不是完全小写的，也找到 plone.recipe.zope2instance 食谱。当 zope2instance 食谱本身混合大小写时，它也能正常工作，因此我们也应该接受这一点。[maurits]

2.21 (2015-10-06)

• 在恢复时，如果需要，则创建 var/filestorage。修复 #23。[maurits]

2.20 (2014-11-11)

• 添加 enable_fullbackup 选项。默认值：true，因此与上一版本相比没有变化。[maurits]

• 仅在需要时创建备份/快照/zipbackup 目录。运行备份脚本不应创建快照目录。[maurits]

• 当 enable_zipbackup = true 时添加 zipbackup 和 ziprestore 脚本。[maurits]

2.19 (2014-06-16)

• 在制作增量备份时使用 --quick 调用 repozo。这要快得多。理论上，如果有人在您的备份目录中捣乱，这会导致不一致。您可以通过在 buildout 配置的备份食谱部分中指定 quick = false 来返回以前的行为。[maurits]

• 现在在运行 pre_commands 之后发生检查和创建文件夹操作 [@djay]

2.18 (2014-04-29)

• 添加 rsync_options 选项。这些被添加到默认的 rsync -a 命令中。默认为没有额外参数。这可以在您想要从符号链接目录恢复备份时很有用，在这种情况下 rsync_options = --no-l -k 会起到作用。[fiterbek]

2.17 (2014-02-07)

• 增加 alternative_restore_sources 选项。这会创建一个 bin/altrestore 脚本，可以从指定的替代备份位置恢复，该位置由该选项指定。您可以使用它来将生产数据的备份恢复到您的测试或预发布服务器。[maurits]

• 在检查备份脚本是否能创建路径时，删除所有创建的目录。直到现在，只有最后一个目录被删除，而不是任何创建的父目录。[maurits]

• 测试：将单个大 doctest 文件拆分为多个文件，以便使自动测试之间的依赖性降低，更容易更改和添加新的测试。[maurits]

• 不再用 Python 2.4 进行测试，因为 Travis 不支持它。[maurits]

2.16 (2014-01-14)

• 当不备份 blob 时，不创建 blob 备份目录。当不备份文件存储时，不创建文件存储备份目录。修复了 https://github.com/collective/collective.recipe.backup/issues/17 [maurits]

2.15 (2013-09-16)

• 恢复与 Python 2.4（Plone 3）的兼容性。[maurits]

2.14 (2013-09-09)

• 使用 buildout 选项 gzip_blob 归档 blob 备份。[matejc]

2.13 (2013-07-15)

• 当我们打印出由于运行 repozo 错误而停止执行时，实际上停止执行。[maurits]

2.12 (2013-06-28)

• 现在在启动 backup 或 fullbackup 或 snapshotbackup 脚本时创建备份目录，而不再是初始化期间。[bsuttor]

2.11 (2013-05-06)

• 打印将恢复的文件存储和 blob 存储的名称。问题 #8。[maurits]

• 添加了新的命令行参数：--no-prompt 禁用在恢复备份或快照时的用户输入。对 shell 脚本很有用。[bouchardsyl]

• 修复了带有许多参数而不是仅日期的命令行行为。[bouchardsyl]

2.10 (2013-03-30)

• 添加了 fullbackup 脚本，默认值为 full=true。这可以通过创建一个新的部分来处理，但它似乎没有必要生成完整的新备份脚本集，只是为了得到一个完整的备份。[spanky]

2.9 (2013-03-06)

• 修复了可能的 KeyError: blob_snapshot_location。[gforcada]

2.8 (2012-11-13)

• 修复了可能的 KeyError: blob_backup_location。 https://github.com/collective/collective.recipe.backup/issues/3 [maurits]

2.7 (2012-09-27)

• 改进了 additional_filestorages：支持 blob 和自定义位置。[mamico]

2.6 (2012-08-29)

• 添加了 pre_command 和 post_command 选项。请参阅文档。[maurits]

2.5 (2012-08-08)

• 将代码移至 github：https://github.com/collective/collective.recipe.backup [maurits]

2.4 (2011-12-20)

• 修复了由于缩进错误而阻止旧 blob 备份在超过 keep_blob_days 天时被删除的问题。[maurits]

2.3 (2011-10-05)

• 当 repozo 调用返回错误时，退出备份或恢复的其余部分。主要用例：当恢复到特定日期时，如果找不到文件，repozo 将会错误退出，因此我们也不应尝试恢复 blob。[maurits]

• 允许将 blob 恢复到指定的日期。[maurits]

2.2 (2011-09-14)

• 重构了脚本生成，使初始化代码和脚本参数之间有分割。这恢复了与 zc.buildout 1.5 和系统 Python 的兼容性。实际上，我们不再创建所谓的“站点包安全脚本”，而是创建适用于所有 zc.buildout 版本的普通脚本。[maurits]

• 添加了选项 keep_blob_days，默认情况下指定仅对部分备份保留 14 天的备份。请参阅文档。[maurits]

• 在执行快照备份时删除旧的 blob 备份。[maurits]

2.1 (2011-09-01)

• 当四个备份位置选项（blobbackuplocation、blobsnapshotlocation、location 和 snapshotlocation）不是四个不同的位置（或空字符串）时，引发错误。[maurits]

• 修复了可能的 TypeError: ‘Option values must be strings’。由 Alex Clark 发现，谢谢。[maurits]

2.0 (2011-08-26)

• 使用 rsync 备份和恢复 blob。[maurits]

• 在执行恢复之前询问用户是否确定。[maurits]

1.7 (2010-12-10)

• 修复生成的 repozo 命令，使其也能在配方配置为具有非 Data.fs 主数据库加上额外的文件存储时工作。例如：datafs= var/filestorage/main.fs additional = catalog [hplocher]

1.6 (2010-09-21)

• 添加了 enable_snapshotrestore 选项，以便可以删除脚本的创建。向后兼容，如果您没有指定它，脚本仍然会被创建。理由：您可能不希望在生产构建中包含此脚本，错误地使用 snapshotrestore 而不是 snapshotbackup 可能会带来损害。[fredvd]

1.5 (2010-09-08)

• 修复：当在单独的目录（如 bin/buildout -c conf/prod.cfg）中运行构建时，默认的备份目录不再创建在该单独目录内。如果您之前手动指定了位置、snapshotlocation 或 datafs 参数以解决这个问题，您可能可以删除这些行。因此：略微更合理的默认值。[maurits]

1.4 (2010-08-06)

• 添加了有关如何获取所需 bin/repozo 脚本的文档，如果出于某种原因您还没有它（例如在 Plone 4 上没有 zeo 设置）。感谢 Vincent Fretin 提供额外的构建脚本。[maurits]

1.3 (2009-12-08)

• 添加了 snapshotrestore 脚本。[Nejc Zupan]

1.2 (2009-10-26)

• 现在创建的脚本和 var/ 目录中反映了部分名称。最初，bin/backup、bin/snapshotbackup、bin/restore 以及 var/backups 和 var/snapshotbackups 都是硬编码的。当您将部分命名为 [backup] 时，您会得到 bin/NAME、bin/NAME-snapshot、bin/NAME-restore 以及 var/NAMEs 和 var/NAME-snapshots。这是由 aclark 为 plone.org 提出的请求。[reinout]

1.1 (2009-08-21)

• 为额外的文件存储运行清理脚本（删除我们不再想保留的过时备份）。修复了 https://bugs.launchpad.net/collective.buildout/+bug/408224 [maurits]

• 将所有内容移入 src/ 子目录，以简化在 buildbot 上的测试（buildbot 会抓取 eggs/ 目录中 buildbot 机制创建的所有 egss）。[reinout]

1.0 (2009-02-06)

• 引用所有路径和参数，以便在包含空格的路径（特别是在 Windows 上）上也能正常工作。[sidnei]

0.9 (2008-12-05)

• 修复了 Windows 路径兼容性问题。[Juan A. Diaz]

0.8 (2008-09-23)

• 将默认的 gzipping 设置为 True。将 gzip = true 添加到所有我们的服务器部署配置中会很快变得令人厌倦，所以默认设置是最好的默认值。此类更改需要在 1.0 版本发布之前进行更改：之前。[reinout]

• 现在在备份主数据库之前（同样也适用于恢复）会备份额外的数据库（如果您已配置它们）。[reinout]

0.7 (2008-09-19)

• 添加了 $BACKUP 样式的环境变量替换，除了 0.6 提供的波浪号展开外。[reinout，由 Fred van Dijk 提出][maurits]

0.6 (2008-09-19)

• 修复了测试设置，以便 bin/test 和 python setup.py test 都能工作。[reinout+maurits]

• 添加了对路径名称中 ~ 的支持。同时修复了同时使用非绝对备份位置从不同于构建目录的位置调用备份脚本时发生的错误。[reinout]

0.5 (2008-09-18)

• 添加了对 additional_filestorages 选项的支持，这对于例如分离的 catalog.fs 是必需的。[reinout]

• 测试设置修复。[reinout+maurits]

0.4 (2008-08-19)

• 允许用户通过使用 'bin/backup -q'（或 –quiet）来使脚本更安静（例如在 cronjob 中）。[maurits]

• 重构了初始化模板，使其更容易更改。[maurits]

0.3.1 (2008-07-04)

• 添加了 'gzip' 选项，包括对清理功能的变化，该功能将 .fsz 也视为与 .fs 一样的完整备份。[reinout]

• 修复了拼写错误：repoze 现在在所有地方都变成了 repozo…[reinout]

0.2 (2008-07-03)

• 为 'keep' 添加了额外的测试和文档更改：默认保留 2 个备份而不是所有备份。[reinout]

• 如果 debug=true，则 repozo 也会在 –verbose 模式下运行。[reinout]

0.1 (2008-07-03)

• 添加了 bin/restore。[reinout]

• 添加了快照备份。[reinout]

• 启用了清理旧备份的功能。[reinout]

• 这是第一个可以运行 repozo 并在需要时创建备份目录的工作版本。[reinout]

• 基于 zopeskel 模板开始项目。[reinout]