自动保留最新的数据存储备份
Automatically retain latest datastore backup
我正在寻找最佳策略来收集存储在 Cloud Storage 中的特定数据存储区 *.backup_info 文件并将它们复制为每种 "latest" backup_info 文件，所以我每种都有一个固定位置，找到最新的 backup_info 文件，例如
gs://MY-PROJECT.appspot.com/latest/Comment.backup_info
基本上，我有一个 Google App Engine 应用程序（Python 标准），其中包含云数据存储中的数据。我可以 运行 a cron-job 按照文档 Scheduled Backups and I can also write a bit of Python code to execute backup tasks which is triggered manually as described in this SO answer 中的描述自动定期执行备份。我计划编写一个小的 Python cron-job 来执行任务以查找给定类型的最新 backup_info 文件并将其 copy/rename 到所需位置。
无论哪种方式，原始备份位置在一天内都会挤满大量文件和文件夹，尤其是当某种类型有多个备份时。例如在 gs://MY-PROJECT.appspot.com/ 我会发现：
VeryLoooooongRandomLookingString.backup_info
OtherStringForSecondBackup.backup_info
OtherStringForThirdBackup.backup_info
该字符串似乎是每次备份执行的唯一标识符。我假设，它包含一个 *.backup_info 文件列表，备份中的每种文件一个。
VeryLoooooongRandomLookingString.Comment.backup_info
OtherStringForSecondBackup.Comment.backup_info
OtherStringForThirdBackup.Comment.backup_info
对于备份中的每一种，例如"Comment"。好像里面有这种和这个备份的实际备份数据的列表。
datastore_backup_CUSTOM_PREFIX_2017_09_20_Comment/
datastore_backup_CUSTOM_PREFIX_2017_09_20_1_Comment/
datastore_backup_CUSTOM_PREFIX_2017_09_20_2_Comment/
每个备份和种类的数据文件夹。在此求助"Comment"，9月20日备份3次
我的问题与 Datastore and/or Storage:
有关
- 是否可以在调用
/_ah/datastore_admin/backup.create 时明确指定自定义 UID 作为查询参数（或在 HTTP header 中）？
- 如果没有，是否可以在备份完成后将带有 UID 的消息发送到挂钩或其他东西？
- 如果 (1) 和 (2) 不可能：在 Storage 中找到给定的最新 *.backup_info 文件的最佳方法种类？似乎 listbucket() 不允许过滤，而且我认为遍历数百或数千个文件以查找特定名称模式不会有效。
我找到了两个解决方案，一个在 GA 中，一个在 Beta 中。
答案简而言之：
GA Datastore Export & Import service 允许自定义和可预测的备份路径
及其 long-running operations 的 API 允许获取备份作业的输出 URL（例如，对于带有时间戳的路径）。
由 Cloud Storage 事件触发的 Cloud Function 将允许在将特定 [KIND].backup_info 文件添加到存储桶后立即处理它们，而不是分页浏览存储桶中的数千个文件每次.
数据存储导出和导入
此新服务有一个 API 到 运行 个导出作业 (manually or scheduled)。该作业允许指定路径并生成可预测的完整路径，因此如果任何时候只需要最新的备份，现有的备份文件可能会被覆盖，例如：
gs://[YOUR_BUCKET]/[PATH]/[NAMESPACE]/[KIND]/[NAMESPACE]_[KIND].export_metadata
对于 cron-jobs，App Engine 处理程序 URL 是 /cloud-datastore-export（而不是旧的 /_ah/datastore_admin/backup.create）。导出的格式也不同于旧的导出。它也可以导入 BigQuery，就像旧的 [KIND].backup_info 文件一样。
云函数
部署由备份存储桶中的任何更改触发的云函数 (JavaScript / Node.js)，如果该文件存在 (file.resourceState === 'not_exists')，则它是新的 (file.metageneration === '1') 实际上是我们想要的 [KIND].backup_info 文件之一，它将被复制到不同的存储桶（"latest_backups" 左右）。副本上的自定义元数据可用于在函数的后续执行中比较 timeCreated（这样我们就不会意外地用旧文件覆盖更新的备份文件）。不过，复制或移动实际备份负载会破坏 [KINDNAME].backup_info 文件中的引用。
我正在寻找最佳策略来收集存储在 Cloud Storage 中的特定数据存储区 *.backup_info 文件并将它们复制为每种 "latest" backup_info 文件，所以我每种都有一个固定位置，找到最新的 backup_info 文件，例如
gs://MY-PROJECT.appspot.com/latest/Comment.backup_info
基本上，我有一个 Google App Engine 应用程序（Python 标准），其中包含云数据存储中的数据。我可以 运行 a cron-job 按照文档 Scheduled Backups and I can also write a bit of Python code to execute backup tasks which is triggered manually as described in this SO answer 中的描述自动定期执行备份。我计划编写一个小的 Python cron-job 来执行任务以查找给定类型的最新 backup_info 文件并将其 copy/rename 到所需位置。
无论哪种方式，原始备份位置在一天内都会挤满大量文件和文件夹，尤其是当某种类型有多个备份时。例如在 gs://MY-PROJECT.appspot.com/ 我会发现：
VeryLoooooongRandomLookingString.backup_info
OtherStringForSecondBackup.backup_info
OtherStringForThirdBackup.backup_info
该字符串似乎是每次备份执行的唯一标识符。我假设，它包含一个 *.backup_info 文件列表，备份中的每种文件一个。
VeryLoooooongRandomLookingString.Comment.backup_info
OtherStringForSecondBackup.Comment.backup_info
OtherStringForThirdBackup.Comment.backup_info
对于备份中的每一种，例如"Comment"。好像里面有这种和这个备份的实际备份数据的列表。
datastore_backup_CUSTOM_PREFIX_2017_09_20_Comment/
datastore_backup_CUSTOM_PREFIX_2017_09_20_1_Comment/
datastore_backup_CUSTOM_PREFIX_2017_09_20_2_Comment/
每个备份和种类的数据文件夹。在此求助"Comment"，9月20日备份3次
我的问题与 Datastore and/or Storage:
有关- 是否可以在调用
/_ah/datastore_admin/backup.create时明确指定自定义 UID 作为查询参数（或在 HTTP header 中）？ - 如果没有，是否可以在备份完成后将带有 UID 的消息发送到挂钩或其他东西？
- 如果 (1) 和 (2) 不可能：在 Storage 中找到给定的最新 *.backup_info 文件的最佳方法种类？似乎 listbucket() 不允许过滤，而且我认为遍历数百或数千个文件以查找特定名称模式不会有效。
我找到了两个解决方案，一个在 GA 中，一个在 Beta 中。
答案简而言之：
GA Datastore Export & Import service 允许自定义和可预测的备份路径
及其 long-running operations 的 API 允许获取备份作业的输出 URL（例如，对于带有时间戳的路径）。
由 Cloud Storage 事件触发的 Cloud Function 将允许在将特定
[KIND].backup_info文件添加到存储桶后立即处理它们，而不是分页浏览存储桶中的数千个文件每次.
数据存储导出和导入
此新服务有一个 API 到 运行 个导出作业 (manually or scheduled)。该作业允许指定路径并生成可预测的完整路径，因此如果任何时候只需要最新的备份，现有的备份文件可能会被覆盖，例如：
gs://[YOUR_BUCKET]/[PATH]/[NAMESPACE]/[KIND]/[NAMESPACE]_[KIND].export_metadata
对于 cron-jobs，App Engine 处理程序 URL 是 /cloud-datastore-export（而不是旧的 /_ah/datastore_admin/backup.create）。导出的格式也不同于旧的导出。它也可以导入 BigQuery，就像旧的 [KIND].backup_info 文件一样。
云函数
部署由备份存储桶中的任何更改触发的云函数 (JavaScript / Node.js)，如果该文件存在 (file.resourceState === 'not_exists')，则它是新的 (file.metageneration === '1') 实际上是我们想要的 [KIND].backup_info 文件之一，它将被复制到不同的存储桶（"latest_backups" 左右）。副本上的自定义元数据可用于在函数的后续执行中比较 timeCreated（这样我们就不会意外地用旧文件覆盖更新的备份文件）。不过，复制或移动实际备份负载会破坏 [KINDNAME].backup_info 文件中的引用。