问题标签 [backups]

我们在同一个 S3 存储桶中备份工具的主目录和配置，按目录名称分隔。我们在 S3 存储桶上启用了版本控制。--delete由于担心在 S3 备份中丢失重要文件，如果我们的分布式文件系统和计划的 S3 同步作业运行出现问题 - 我们在 s3 同步期间没有启用选项。

现在，我想知道 - 如果本地备份出现问题并且我们意识到 - 假设 4 天后 - 我们需要在just one directoryS3 存储桶中恢复 4 天前的文件，我该如何实现？

此外，如果您能回答 - 由于我们没有启用--delete选项，因此恢复还将恢复所有已删除或本地不存在的文件 - 不再需要 - 我们如何在恢复期间避免这种情况？

我正在使用docker部署我的gitlab服务，但是gitlab没有删除备份文件，导致文件太大。

我看到，就 Google CloudSQL 的自动备份而言，我们只有以下选项：

• 每天一次完整备份
• 如果启用了二进制日志，则在两者之间进行时间点恢复
• 备份保留 7 天

如果我想在白天进行更多备份，我有什么选择，比如说每 6 小时进行一次完整备份，循环日志，保留 3 个月的备份。

那可能吗？

它看起来不是基于本机控制台，即没有选项可以定制备份策略，例如在 Mongo Cloud Manager 中，它允许非常好的备份集粒度。

我正在尝试为本地事务日志备份创建维护计划。

完整备份的位置被列为 Azure 地址 ({C58FA3E7-ABB7-........})，因此维护计划认为没有完整备份。

是否仍然可以在不访问 Azure 的情况下创建本地事务日志备份？

现在唯一能让 tlog 备份不失败的方法是在本地磁盘上手动创建一个新的完整备份。

我有一个生产 SQL Server 数据库 (2008R2)，每晚执行完整备份。备份的总时间大约需要 20 分钟。在完整备份期间，如果有任何东西试图连接或与数据库交互，则似乎数据库处于脱机状态，或者它们的连接超时。

我已经读过在执行完整备份时，仍然会捕获任何活动的 CRUD 操作，因为备份包括 DB 文件和日志文件。

我想知道的是，在执行完整备份时是否可以让数据库仍然处于活动状态（即使是读取）？还是我需要接受每天晚上，我的数据库将在一段时间内不可用？

仅供参考 - 我正在使用标准备份命令来执行备份： BACKUP DATABASE [xxxx] TO DISK = 'xxBackupFilePathxx' WITH COMPRESSION

我维护一些备份，每天的 cron 作业，并且我正在寻求实现一个更复杂的系统，只使用bash和常见的 Unix/Linux 实用程序（例如GNU date）来老化旧档案。

我要实施的政策是这样的：

• 每个月留一个，永远
• 每周保持 1 次，持续 13 周（约 3 个月）
• 删除超过 14 天的所有其他内容

我草拟的脚本将这些作为（硬）链接维护在./monthly和./weekly 中（相对于$BASEDIR）。

它看起来像这样：

但是，什么是对极端情况进行测试的合理方法呢？我可以看到的一个是如果备份/日志在给定的一天内无法运行（系统在 cron 应该运行时已关闭）......那么 glob 将无法匹配任何文件，因此[ -r "$f" ]将失败并且没有修剪将会完成。这似乎无害（我得到了额外的一天备份。如果有人弄乱了备份的权限，那么-r即使存在匹配的文件也可能失败（但这是一个更大的问题）。

（注意：这只是准备本地应用程序备份文件的系统的一部分。有一个完全不同的系统将它们全部收集在中央存储上）。

不过，似乎应该有一种更优雅的方式来完成这一切！

是否有find类似的实用程序采用某种保留规范并在树中生成与规范不匹配的文件列表？

我已经安排我的 Heroku 生产数据库每天进行备份，我也想每天将备份恢复到我的暂存数据库中。通过这种方式，我可以使暂存盒与生产环境保持同步以进行测试/调试，并自动运行恢复过程的每日测试。

我试图安排一个 bash 脚本在暂存盒上运行以执行还原。我的脚本使用 Heroku CLI 提取最新备份的 url 并执行恢复。我遇到的问题是验证 Heroku CLI。由于我无法在测功机上打开浏览器，因此我需要找到一种安全的身份验证方式。

我应该从某个地方拉一个 .netrc 文件吗？给测功机提供 CLI 甚至是个好主意吗？有没有更好的方法来解决这个问题而无需建立另一台服务器来运行恢复？

我正在使用 spatie 的 laravel-backup 来备份我的 laravel 应用程序文件和数据库，并将它们存储在数字海洋空间中。这对我来说很好。

我有另一个数字海洋空间，被上传的用户文件被存储到。

我的问题是。我还需要备份数字海洋空间吗？还是可以信任他们？数字海洋会以某种方式自行备份空间吗？

这是我用来备份我的东西的配置文件：

你们是如何处理备份用户文件的？

系统信息：

Laravel 5.8.28 MySQL 5.7 PHP 7.2

我将 Percona 5.7.18-16 用于我的 MySQL (Percona) 数据库服务器。

我正在使用 Percona xtrabackup 2.4.8 对正在运行的服务器进行实时备份。

我已经设置了一个测试服务器来验证从上述主服务器进行的备份。

测试服务器也在运行 Percona 5.7.18-16。

我发现 Percona xtrabackup 2.4.8 几乎 - 从来没有 - 做一个可行的备份......即使它报告“完成正常！” 完成备份阶段时在 CLI 中。在测试服务器上，大约有 80% 的时间在备份损坏时损坏索引，有时在恢复备份时表本身也损坏。

在验证服务器上运行“检查表表名”会使 innodb 中的验证服务器崩溃，每次备份都会出现各种表和索引损坏。

实时数据库的大小约为 400GB。我通过 sha256sum 确保我在测试服务器上恢复的 .tar 与源/主服务器上的二进制完全相同。我用

将 xtrabackup 生成的目录的 .tar 传输到验证/测试服务器。

我通过 innobackupex 符号链接调用它，例如

接着

以这种方式生成的备份中约有 90% 已损坏，xtrabackup 在生成备份后没有报告任何错误或故障。对于企业应用程序来说，这是一个惊人的失败率。

关于我可以尝试解决这个问题的任何想法？Xtrabackup 似乎是一种常见且流行的工具。

我在实时服务器的表上运行了一个“检查表......”，它很干净。此时其上的 5.7 Percona 实例运行了大约 370 天。在过去的一年里，它每 24 小时处理大约 2500 万次插入和大约 3000 万次更新。

但事实证明，使用 xtrabackup 进行一致备份是不可能的。

任何指针？有人遇到过这种情况吗？如何获得 xtrabackup 以对 Percona 5.7 实例进行一致的备份？

谢谢！

斯特凡

我正在使用 mongorestore 4.2 mongorestore --gzip --archive=my-archive.gz来恢复使用 mongodump 3.2（ish？）制作的备份，这个过程非常非常慢。就像我什至没有看到一个完成，因为它已经慢了 3 天。这是 mongorestore 和旧 mongodump 备份之间版本不匹配的报告问题吗？