通常，当我在新环境中开始时，我倾向于检查备份在哪里，最后一次完整的时间，最后一次应用的还原时间，我也会检查安全性。
我这样做的方式是通过 T-SQL。
检查备份
;with Radhe as (
SELECT @@Servername as [Server_Name],
B.name as Database_Name,
ISNULL(STR(ABS(DATEDIFF(day, GetDate(), MAX(Backup_finish_date)))), 'NEVER') as DaysSinceLastBackup,
ISNULL(Convert(char(11), MAX(backup_finish_date), 113)+ ' ' + CONVERT(VARCHAR(8),MAX(backup_finish_date),108), 'NEVER') as LastBackupDate
,BackupSize_GB=CAST(COALESCE(MAX(A.BACKUP_SIZE),0)/1024.00/1024.00/1024.00 AS NUMERIC(18,2))
,BackupSize_MB=CAST(COALESCE(MAX(A.BACKUP_SIZE),0)/1024.00/1024.00 AS NUMERIC(18,2))
,media_set_id = MAX(A.media_set_id)
,[AVG Backup Duration]= AVG(CAST(DATEDIFF(s, A.backup_start_date, A.backup_finish_date) AS int))
,[Longest Backup Duration]= MAX(CAST(DATEDIFF(s, A.backup_start_date, A.backup_finish_date) AS int))
,A.type
FROM sys.databases B
LEFT OUTER JOIN msdb.dbo.backupset A
ON A.database_name = B.name
AND A.is_copy_only = 0
AND (A.type = 'D') --'D' full, 'L' …我有一个名为“A”的数据库，它有两个模式“B”和“C”。
我想在不同的服务器上备份和恢复架构“B”（包括数据）。不知道如何做到这一点，因为我是 Postgres 的新手。
我是否必须在名为“A”的新服务器上创建一个新数据库，然后在其上恢复架构“B”？
请帮助执行必要的命令。
在 Ubuntu 12.04 上运行的 PostgreSQL 9.1
场景：您收到了一个数据库备份，并被告知将其还原到服务器（该服务器已经托管了其他数据库），但没有提供有关备份包含的内容或源是否应受信任的有用信息。
问题 1：恢复很可能是恶意的备份有什么潜在影响？
问题 2：您可以采取哪些措施来保护您的服务器/其他数据库中的数据免受恢复潜在恶意备份的影响？RESTORE VERIFYONLY似乎是一个很好的第一步。最终的答案可能是“在无法访问外部世界的沙箱 VM 中恢复数据库”，但让我们假设该选项不在表中。在这种情况下还应该做什么？
我的任务是为 MongoDB 副本集设置增量备份，作为起点，当然，我用谷歌搜索它并在 MongoDB 文档上找不到任何内容，但我确实在 Stack Overflow 上找到了这个问题，这鼓励开发我自己的解决方案因为没有发现 Tayra 很活跃。
我阅读oplog并意识到开发一些东西来重播日志非常容易，但事实证明我没有必要像mongorestore我那样这样做。
现在我有了一个使用 bash 脚本的有效解决方案，而且非常简单，这就是我在这里询问我的逻辑是否有任何缺陷的原因，或者将来可能会咬我的东西。
下面我是如何实现的：
锁定在次要成员上写入 db.fsyncLock()
拍摄快照
记录 oplog 的最后一个位置
db.oplog.rs.find().sort({$natural:-1}).limit(1).next().ts
解锁写入 db.fsyncUnlock()
锁定在次要成员上写入
在完整（或最新的增量）备份上从记录的 oplog 位置转储 oplog：
mongodump --host <secondary> -d local -c oplog.rs -o /mnt/mongo-test_backup/1
--query '{ "ts" : { $gt : Timestamp(1437725201, 50) } }'
记录最新的 oplog 位置（与完整备份相同）
解锁写入
mongodlocal*，mongod.lock 这种还原技术称为通过破坏镜像重新配置local数据库从新主数据库复制数据当我们创建增量备份时，它的存储方式如下：
/mnt/mongo-test_backup/1/local/oplog.rs.bson
/mnt/mongo-test_backup/1/local/oplog.rs.metadata.json
我们被插入 …
通常我们每周的完整备份在大约 35 分钟内完成，每日差异备份在大约 5 分钟内完成。从星期二开始，每天的日常工作需要将近 4 个小时才能完成，远远超出了应有的要求。巧合的是，这在我们获得新的 SAN/磁盘配置后立即开始发生。
请注意，服务器正在生产中运行，我们没有整体问题，它运行平稳 - 除了主要表现在备份性能中的 IO 问题。
在备份期间查看 dm_exec_requests，备份一直在等待 ASYNC_IO_COMPLETION。啊哈，所以我们有磁盘争用！
但是，MDF（日志存储在本地磁盘上）和备份驱动器都没有任何活动（IOPS ~= 0 - 我们有足够的内存）。磁盘队列长度 ~= 0 也是如此。CPU 徘徊在 2-3% 左右，也没有问题。
SAN 是 Dell MD3220i，LUN 由 6x10k SAS 驱动器组成。服务器通过两条物理路径连接到 SAN，每条路径都通过一个单独的交换机与 SAN 的冗余连接 - 总共有四个路径，其中两个随时处于活动状态。我可以通过任务管理器验证两个连接是否都处于活动状态 - 完美均匀地分配负载。两个连接都运行 1G 全双工。
我们曾经使用巨型帧，但我已禁用它们以排除此处的任何问题 - 没有变化。我们有另一台服务器（相同的操作系统 + 配置，2008 R2）连接到其他 LUN，它没有显示任何问题。然而，它没有运行 SQL Server，而只是在它们之上共享 CIFS。但是，它的 LUN 首选路径之一与麻烦的 LUN 位于同一 SAN 控制器上 - 所以我也排除了这一点。
尽管存在以下问题，但运行几个 SQLIO 测试（10G 测试文件）似乎表明 IO 是不错的：
sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 3582.20 …在使用 mysqldump 之类的东西之前，如何确定或估计 SQL 转储文件的大小？
我们有一个客户的 bak 文件，我们已将其转移到我们的开发人员办公室进行问题调查。备份当前为 25GB，还原的数据库大小大致相同，但需要 100GB 才能还原。我相信这是因为数据库设置为具有 75GB 的事务日志大小。恢复数据库后，我们可以缩小日志文件，但有没有办法在恢复中做到这一点？
在备份数据库时，我想使用“备份集将过期： ”选项来删除/覆盖旧的数据库备份。我无法使用此选项。
关于如何在创建维护计划时使用“备份集将过期：”选项的任何建议将不胜感激。
我想将数据从一个数据库合并到另一个数据库。所以我创建转储，mysqldump然后将其导入另一个数据库（具有相同的表结构）。在这种情况下，我没有任何问题（例如重复条目或其他问题）。
但是为了测试目的我做了一些合并，稍后我会做最终合并。所以，我想执行几次合并（数据可能会更改）。请注意，我的表中的行永远不会删除，只能插入或更新。
我可以使用 ON DUPLICATE 选项创建 mysqldump 吗？或者我可以合并插入新数据并更新修改数据的转储？
当然，我可以ON DUPLICATE手动插入转储，但我想自动化合并过程。
backup ×10
sql-server ×4
mysql ×3
mysqldump ×3
export ×2
restore ×2
security ×2
maintenance ×1
mongodb ×1
network ×1
postgresql ×1
san ×1
schema ×1