标签: backup

我有一个测试数据库，我定期从 SQL Server 2008 R2 中的生产备份文件中恢复该数据库以获取新数据。与生产的存储过程相比，我们经常编辑\更改或更新测试数据库中的存储过程来测试数据！

是否只刷新\恢复表而不是存储过程？所以我不必将它们重新编辑回我需要的更改？

这两个数据库（生产和测试）都在一台服务器上。

我的数据库大小约为 5 GB，我们负担不起第三方工具。

创建备份时，SQL Server 会猜测（？）初始备份文件的大小。稍后，也许当它附加日志时，大小会被重新调整，有时会多次调整，直到达到最终大小。差异越大，备份所需的时间就越长。（与另一个备份相比，稍后不会调整大小）。示例：Database1（大小为 500GB，使用了 70GB 的日志）通过压缩进行备份。创建的 .bak 文件大小为 85 GB，一段时间后 CPU 使用率上升，我可以看到 .bak 文件重新调整为 136 GB，这种情况再次发生，直到备份的最终大小为 178GB到达。

当这些重新计算发生时，与同一台机器上的其他备份相比，以 MB/s 为单位的平均备份速度会降低。唯一来自附加和清除日志吗？还是因为数据库中使用的数据类型不同？意味着它们以不同的压缩率压缩，或者其他什么？

我来到这个话题，因为我知道我的备份需要大约 30 分钟，但现在即使数据库没有增长到其大小的 300%，也需要 1.5 小时。它仅增长了 30%。

使用等待统计数据，我可以看到除了 BackupIO 之外，我还在某个时候等待 CPU (SOS_SCHEDULER_YIELD)。

Machine Details:
VMWare 6.0 
32 GB of Memory (Max memory 28GB given to SQL Server)
2 logical CPU
Max Degree of Parallelism (1, it's a Sharepoint 2013)   
SQL Server 2014
Windows Server 2012 R2
running on an SSD Raid (5)

当然，我为运行备份的用户启用了即时文件初始化。

为了提高我们的 SQL Server 备份的性能，我们备份到多个备份文件。

• 在有关此主题的大多数博客文章中，他们都说要使用多个备份文件，但是，是否存在由于大量线程等待而导致文件过多而不是提高性能反而会导致性能下降的情况？
• 是否有任何基于例如服务器内核数的一般建议？更具体地说，我们的其中一台服务器显示 BACKUPIO并BACKUPBUFFER作为前 2 名违规者的等待统计数据。

我们正在使用 10 个备份文件备份一个大数据库（几个 TB），但我注意到服务器只有 4 个内核和 32 GB 的 RAM。我已将备份文件的数量更改为使用 4 个备份文件。我将在下周的下一个备份周期中看到它的进展情况，但与此同时，我试图根据服务器规格找到有关使用多少备份文件的任何建议。

我在文档中看到数据库备份工具分为四类：热备份、冷备份、物理备份和逻辑备份。

我理解冷备份和热备份最重要的区别是后者可以在数据库运行和接收读写查询时完成（并且结果将是一致的和原子的）。

但是，我怎么知道 mysqldump 有这个“热”方面还是“冷”方面？文档只是将它放在logical backup类别中，对此并不是 100% 清楚（是的，它似乎提到它在 mysqldump 过程开始时使用相同的数据库快照，这表明它绝对是一个热备份工具，但是只是想在这里仔细检查一下）。

这些表使用 InnoDB 引擎。

这个问题可能读起来像是重复的，但是是基于情况的，并且是从应用其他答案中的知识的混淆中发布的。

我已经阅读了数十篇文章（在1、2、3、4 中），但我发现了相互矛盾的观点（根据我的理解，现在信息过载，或者我的其他问题中可能没有包含足够的信息）。因此，我创建这个问题是为了根据我的情况获得明确的答案。

鉴于以下备份场景，我需要知道第三方备份软件是否会阻止我执行完整恢复到最新备份点（18:00）？

Time  | Action                                       | Device   
------|----------------------------------------------|----------------------------
12:00 | Full backup (non copy_only)                  | D:\MyBackupDevice                 
13:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
14:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
15:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                 
16:00 | Full backup (non copy_only) VSS snapshot     | Third-party off-site device
17:00 | Tran log backup (non copy_only)              | D:\MyBackupDevice                
18:00 | Tran log backup …

我有一个 10.6GB 的 MySQL 数据库——它有 MyISAM 和 InnoDB 表。一个特定的表（称为“响应”）是 8Gb - 该表是 InnoDB。

实时数据库被复制到另一台服务器，我使用 MySQLDump 从复制服务器进行备份……实时服务器运行 Windows，但复制服务器运行 CentOS。

MySQLDump 命令是：

mysqldump --verbose --lock-tables=true --max-allowed-packet=1024M --host=192.168.1.182 --user=myusername --password=mypassword --opt --databases databasename > databasename.sql

该命令运行到“响应”表的一半 - 当我们得到：错误 2013 - 查询期间在第 12891212 行转储表响应时丢失与 MySQL 服务器的连接

经过一番谷歌搜索后，我尝试将以下命令添加到 MySQLDump（独立和同时）：

--net-buffer-length=32704

和

--skip-extended-insert

错误仍然发生在同一个地方。

为了完整起见，我尝试在 NaviCat 和 MySQL Workbench 中转储数据库 - 两者都返回相同的错误。

所以，我想知道这是否是腐败问题。我尝试运行以下（在复制服务器上）：

CHECK TABLE responses;

和

CHECK TABLE responses EXTENDED;

两者都返回以下内容：错误 2013 - 查询期间与 MySQL 服务器的连接丢失。

实时数据库非常忙，所以我有点担心......我在实时表上启动了CHECK TABLE，但不出所料，它导致应用程序停止，所以我不得不停止它。

这里欢迎任何建议......最终目标是使用 MySQLDump 进行备份。

谢谢

更新：我尝试使用 NaviCat 将表（在复制服务器上）复制到另一台服务器上的新数据库 …

如果它很愚蠢并且有效，那它仍然是愚蠢的。

关于 GDPR 的喧嚣让我思考 - 如果您必须进行备份并修改/删除数据，您会怎么做？破解打开 .bak 文件对我来说听起来很难。但是打开一个 .txt 文件很容易。

我可以将我的数据库备份到文本文件中，从而更轻松地从备份中删除历史记录吗？

我似乎想不出答案。我见过多个这样的答案： 为什么事务日志不断增长或空间不足？

每个人都在谈论在您的日志文件上运行备份，以便它缩小。我正在这样做，但它不会缩小任何东西！我也不相信我正在运行任何超长事务。

服务器： SQL Server 2008

恢复模式： Full

我有一个维护计划来存储 5 天的备份。任务 1 备份具有备份类型的数据库Full，任务 2 备份事务日志。Verify backup integrity对两个任务都进行检查。

我的数据库的正常.ldf文件是 22GB。当我运行上述任务时，.bak文件为435mb，但.trn.文件为22gb，与ldf相同。并且在成功运行之后.ldf根本没有缩小，尽管我读过的所有内容都告诉我应该这样做？

这里发生了什么，为什么日志文件永远不会缩小？

我也试过运行另一个答案中提到的这个命令：

select name, log_reuse_wait_desc from sys.databases

它说LOG_BACKUP的是带有巨大日志文件的数据库。

根据下面的答案，我混淆了已用空间的分配。这些是我的统计数据：

由于我不知道为什么，初始大小设置为 22gb ...

我有一个在 VM 上运行的 MSSQL Express 服务器。我使用的托管服务提供商可以选择创建驱动器快照。服务器一直在运行，并且在驱动器备份期间不会停止。备份没有与 MSSQL 相关的特殊功能。如果我将我的数据文件保存在这样的驱动器上并在灾难恢复时使用快照，是否存在数据库无法恢复的风险？

最近的一个问题让我看着 MS 文档并感到疑惑。

可以将多少个备份附加到单个文件是否有限制？

默认情况下，SQL Server 用于NOINIT将新备份附加到旧备份文件。

{ NOINIT | INIT } 控制备份操作是附加到还是覆盖备份介质上的现有备份集。默认是附加到媒体上的最新备份集 (NOINIT)。来源

文档明确指出，可用磁盘空间不足将导致附加备份失败。

如果在备份操作将备份附加到媒体集时磁盘文件已满，则备份操作将失败。备份文件的最大大小取决于磁盘设备上的可用磁盘空间；因此，备份磁盘设备的适当大小取决于备份的大小。来源

SQL Recover from .bak file with NOINIT的答案表明PositionfromRESTORE HEADERONLY指示文件中的单个备份。这是一个“smallint”字段，最大应为32,767

大多数情况下，在谷歌搜索时，您会发现有人不小心附加了他们的备份，并且无法理解为什么备份如此之大。

假设有足够的磁盘空间，我没有找到任何关于可以附加多少备份的明确参考。极限是 32,767 还是其他什么东西？