标签: backup

我们计划从 SQL Server 2008 R2 升级到 SQL Server 2014，目的是使用可用性组。

其中一个辅助节点将用于进行备份。

我已经测试并发现，只要我有完整的仅复制，以及跨越仅复制到我们想要恢复到的时间的日志备份链，我就可以进行时间点恢复。

我们不使用差速器，也没有计划。

除了可能无法在没有“正常”备份的情况下缩小数据文件之外，我看不出这种方法的任何缺点。我们通常不会缩小我们的数据库，除非我们做一些事情来破坏它们，到那时我们无论如何都处于干预模式。

所以我的问题是，我会后悔走这条路吗？

我正在尝试按照 Craig Ringer 对这个问题的回答：https :
//stackoverflow.com/questions/13758003/how-to-take-backup-of-functions-only-in-postgres

我的命令是：

psql -U username -AT db_name -c "
    SELECT pg_get_functiondef(f.oid) 
    FROM pg_catalog.pg_proc f 
    INNER JOIN pg_catalog.pg_namespace n ON (f.pronamespace = n.oid) 
    WHERE n.nspname = 'public'
" > /dump/file/functions.sql

但我收到以下错误：

Error: "st_extent" is an aggregate function

Run Code Online (Sandbox Code Playgroud)

为什么它不喜欢聚合函数？我该怎么做才能解决这个问题？

我已经通过 PerconaXtrabackup 工具创建了一个 MySQL 备份（感谢本指南）：

innobackupex --user=backupmysqluser --password=xyz --compress --stream=xbstream ./ > /var/backups/db/firstBackup.db

它成功创建了热备份。现在我想测试它的恢复情况，所以，首先，我解压它：

cd /var/backups/db
mkdir decompressed
xbstream -x -C decompressed

现在我试着准备它：

innobackupex --apply-log /var/backups/db/decompressed/

结果是这个错误：

160719 20:06:28 innobackupex: Starting the apply-log operation

IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".

innobackupex version 2.4.3 based on MySQL server 5.7.11 Linux (x86_64) (revision id: 6a46905)
xtrabackup: cd to /var/backups/db/decompressed
xtrabackup: This target seems to be …

我正在运行带有几个客户数据库的 MySQL 服务器，其中一些数据库非常大。我们每天进行一次完整的 mysql 转储。大约需要半个小时才能完成。

在这段时间内，对 MySQL 服务器的每个请求都会得到非常缓慢的响应（有时大约 1 秒而不是 10 毫秒）。即使没有超时错误，我也希望看到查询在相当长的时间内完成，因此客户网站不会因挂起 MySQL 查询而减慢速度。

我研究了很多，了解了数据复制、LVM 快照、各种mysqldump标志选项和其他变通方法，但没有什么能真正改善这种情况。

是否有任何选项可以在 MySQL 中设置查询优先级？

如果有一种方法可以定义查询优先级，我可以给备份进程一个较低的优先级，以确保所有其他查询执行得更快。该mysqldump过程可能会SIGTSTP在受到另一个请求的挑战时暂时暂停 ( )，并SIGCONT在查询完成后继续 ( )。但是，我在 MySQL 中找不到这样的特性。

给mysqldump进程一个更高的nice值是行不通的，因为它只会增加备份进程和表锁存在的时间。（我正在锁定每个表。）此外，限制 IO 写入速率只会导致更长的痛苦。

除了 LVM 和复制之外，还有没有我错过的解决方案？

我了解备份密钥和用户定义的证书的必要性，但是我们是否有任何理由应该备份这些系统创建的证书？

MS_AgentSigningCertificate

MS_PolicySigningCertificate

MS_SchemaSigningCertificate34284BF7CE6208DC9D835E9F45ADD94F0757439E

MS_SmoExtendedSigningCertificate

MS_SQLAuthenticatorCertificate

MS_SQLReplicationSigningCertificate

MS_SQLResourceSigningCertificate

问题陈述： 我们的支持工程师需要从客户那里获取数据库备份。目前，我们的数据库包含在一个 Primary/.mdf 文件组/文件中。这些数据库多年来一直在收集历史数据，并且越来越大。我们的工程师需要几天时间才能将备份复制到我们的办公室。

似乎没有任何规定/想法来管理数据库的增长。

最“有价值”的数据是我们系统的“配置”。它包含在大约 50 个表中，我们正在考虑将这些表移至与历史数据（将放置在数据文件组中）分开的新配置文件组，以尝试为部分或文件备份设置阶段。

但我不确定我需要哪种备份/恢复策略来完成这个 - 部分备份或文件备份？

出于研发目的，我有一个名为FilegroupDemo使用SIMPLE恢复模型的数据库。FilegroupDemo包含 3 个文件组：

• 主要（映射到 FilegroupDemo.mdf）
• 配置（映射到 FilegroupDemo_Configuration.ndf）
• 数据（映射到 FilegroupDemo_Data.ndf）

配置文件组中的数据不会经常更改，并且可能会被标记为只读（如果有帮助），而数据文件组中的数据每分钟更改一次。

我希望能够灵活地仅备份/恢复主文件组和配置文件组/文件。

在SQL Server Partial Backups的 BOL 文章中，它指出：

部分备份类似于完整数据库备份，但部分备份不包含所有文件组。相反，对于读写数据库，部分备份包含主文件组、每个读写文件组以及一个或多个只读文件（可选）中的数据。

这种读取方式让我认为部分备份旨在省略只读文件组，最有可能用于不会更改并标记为只读的大量数据。这些不需要每次都备份。

1. 我说存在部分备份是为了备份所有文件组（除了标记为只读的文件组）是否正确？换句话说，如果我不使用只读文件组，那么使用部分备份就没有意义了——对吗？而且我认为我不能使用部分备份来备份只读文件组？

因此，我不认为部分备份是我所需要的。我相当天真地尝试了文件备份/恢复。我将数据库切换到FULL恢复模式并运行：

BACKUP DATABASE FilegroupDemo FILEGROUP = N'PRIMARY'
TO DISK = N'C:\Backups\FilegroupDemo_FG_Primary.bak'
WITH INIT
GO

BACKUP DATABASE FilegroupDemo FILEGROUP = N'Configuration'
TO DISK = N'C:\Backups\FilegroupDemo_FG_Configuration.bak'
WITH INIT
GO

BACKUP DATABASE FilegroupDemo FILEGROUP …

如果我在 SQL Server 中有一个证书，用于备份：

1. 证书过期后还可以创建备份吗？
2. 证书过期后还可以恢复吗？

让这些证书过期有什么意义？（除了让我暴露于由于过期的证书而导致备份失败......）

我最近在没有太多警告或经验的情况下继承了我们公司的所有 SQL 数据库，并希望通过全面审查备份来给人留下好印象并获得一些快速胜利。

我已经实现了各种完整和 t-log 备份，但在这个盒子上遇到了另一个工作，它在运行之前将数据库设置为简单恢复模式，然后在运行之后恢复到完整模式，不幸的是，这是非常必要的。

我的问题是，如果在凌晨 1 点进行完整备份，并且在此后每小时的顶部进行 t-log 备份，那么在凌晨 5:30 设置简单恢复模式的其他工作是否会破坏“时间线”，例如早上 6 点的完整备份和下一个 t-log 备份？

这是用于这台特定机器的 SQL Enterprise 2012。

欣赏你们的任何见解

我每天在 PostgreSQL 9.3.14 数据库上运行一次 pg_dump。50 GB 大小：

pg_dump -Fc dbname > file

我遇到的问题是，虽然pg_dump运行需要几个小时，但所有其他数据库连接都非常慢。

有什么方法可以减少pg_dump消耗的资源，或者有没有更合适的方法来创建不会大大降低数据库服务器速度的定期备份？

例如，从不同的服务器运行 pg_dump 是否有助于其工作服务器上的数据库 I/O？

今天我收到一个错误 (DTSER_FAILURE)，但我可以通过编辑维护计划来修复它（这个错误是由于维护计划搜索已删除的数据库，而我在设置中使用了“选定的数据库”）。

但是在互联网上，我读了一些帖子说我应该SP_CONFIGURE 'ALLOW UPDATES',0。

这个选项有什么影响？

我在 Microsoft 页面上读到此选项无效并且已弃用。