collective.recipe.backup 4.1.0

兼容性

配方使用Python2.6、2.7和3.6进行测试。 在plone术语中，它在plone 4和plone 5上工作良好。

请注意，与 plone.recipe.zope2instance 的集成没有在python 3.6上进行测试。 此配方及其 mailinglogger 依赖项还没有与python 3兼容的版本。

开发

• 代码库：https://github.com/collective/collective.recipe.backup rel="nofollow">https://github.com/collective/collective.recipe.backup
• 问题跟踪者： https://github.com/collective/collective.recipe.backup/issues
• 很明显的修复，比如修复错别字，对master来说是很好的。 对于较大的更改或如果您不确定，请创建分支或拉取请求。
• 代码附带一个buildout.cfg。请启动 构建并运行创建的 bin/test 以查看测试是否仍然 通过。如果您添加了代码，请尝试添加测试。
• 这个包的详细描述（如pypi所示），用于 包含一个包含大量测试代码的大文件，其中显示了如何使用 食谱。这个长得太大了，所以我们把它忘了。可能是 如果你想知道一些 选项有。参见src/collective/recipe/backup/tests/*.txt。
• 我们在特拉维斯身上做了测试： https://travis ci.org/collective/collective.recipe.backup
• 向https://community.plone.org或向 毛里特斯范里斯

示例用法

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

[buildout]
parts = backup

[backup]
recipe = collective.recipe.backup

你可以设置很多额外的选项，但是菜谱作者喜欢 认为他们已经创建了正常的默认值，所以这一行声明 配方名称在大多数情况下应该足够了。

运行构建将添加 备份 ， 完整备份 ， 快照备份 ， zipbackup ， 还原 ， 快照还原 并将脚本存储到构建的 bin/ 目录。 有些默认情况下不添加，其他可以关闭。

已备份的数据

这个配方备份哪些数据？

• zope对象数据库（zodb）文件存储，默认位于 var/filestorage/data.fs
• 可能还有其他文件存储，请参见 附加文件存储 选项。
• blobstorage（从2.0版开始）如果您的构建使用它，则 默认值位于 var/blobstorage

未备份的数据

这个配方不备份哪些数据？当然，其他的一切， 但具体来说：

• 存储在relstorage中的数据将不会备份。（你可以 仍然使用这个方法来备份文件系统blobstorage， 可能是使用 only_blobs 选项。）
• 存储在sql中的其他数据（可能是通过sqlalchemy存储的）将 备份。
• 它不会为整个构建目录创建备份。

注意，默认情况下，备份是在 var 目录中创建的 如果你不小心把整个建筑都拆了， 也会丢失备份。使用 location 用于指定备份位置的选项，例如 用户的主目录。你也应该安排拷贝 备份到不同的机器/国家/大陆/行星。

备份

调用bin/backup会导致正常的增量repozo备份 这将创建 var/backups 中 data.fs 的备份。当你 具有默认备份到的blob存储 变量/blobstoragebackups

完整备份

调用 bin/full backup 将导致正常的完全repozo备份 这将创建 var/backups 中 data.fs 的备份。当你 具有默认备份到的blob存储 变量/blobstoragebackups 。提供此脚本是为了 为完全备份和增量备份设置不同的cron作业。你可以 希望每天执行增量备份，每周执行完整备份。 现在你可以！

由于版本4.0，默认情况下不创建fullbackup脚本。 通过将enable-fullbackup设置为true来启用它

你通常应该定期做一次，比如说一周一次， 从zope data.fs 中删除未使用的对象。下一次 调用bin/backup 时，将进行完整的新备份，因为 增量备份不再可能。这是标准的 行为。所以你可能不需要 bin/fullbackup 脚本。

快照

在更新生产服务器之前快速备份是一个很好的方法 想法。但你可能不想干扰常规备份 政体。为此， bin/snapshotbackup 非常好。它放置了一个 默认情况下，完全备份在 var/snapshotbackups中

ZipBackups

用于快速获取生产数据库的当前状态，以便 可以下载到你的开发笔记本上，你想要一个完整的和拉链 备份。拉链部分对blobstorage很重要，因为你 不想使用 scp 递归地复制所有这些blob 文件：下载一个tarball更快。

您可以为此使用 bin/zipbackup 脚本。这个脚本 覆盖一些设置，忽略构建中设置的内容 配置部分：

• gzip 显式地为文件存储打开（这是 已经是默认值，但我们会确保）。
• 存档blob 已打开。
• keep 设置为1，以避免保留大量不必要的备份。
• 保留blob天数被忽略，因为它是完全备份。

您还可以从某个日期恢复备份。就给我一个约会的理由。 根据：规范通知UTC（非本地）时间。 格式为：yyyy-mm-dd[-hh[-mm[-ss]] 。 举个简单的例子，恢复到1972年12月25日：

bin/restore 1972-12-25

或者到同一天，在1:03秒之后

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

从版本2.3开始，这也适用于还原blob。 我们在指定日期或之前从第一个备份还原目录。 （注意，在版本4.0之前，我们从指定日期之后的第一次备份还原了目录， 这应该是好的，只要你没有做一个数据库包之间的。）

从版本2.0开始，还原脚本在 启动还原，因为这是一个潜在的危险命令。 （"哦，我已经恢复了现场，但我想恢复测试 site。"）您需要显式键入"yes"：

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

请注意，对于大型文件存储和blobstorage 恢复可能需要很长时间。 您应该执行测试还原并检查它需要多长时间。 秒？几分钟？小时？ 这个时间可以接受吗？还是应该采取其他措施？