标签: backup

我运行以下命令来创建一个 mysqldump

mysqldump -ubackup -psomething --single-transaction --quick somedatabase | gzip > 4_19.gz

在创建转储的 60%（估计 zip 文件的检查大小）后，我收到以下错误：

mysqldump: Couldn't execute 'show table status like 'customer\_cohort\_paid'': SELECT command denied to user ''@'%' for column 'customer_id' in table 'sales_order' (1143)

它谈到了一个空白用户的权限问题user ''@'%'。此外，grants对于backup用户如下：

mysql> show grants for 'backup'@'%';
+------------------------------------------------------------------------------------------------------------------------------------------------+
| Grants for backup@%                                                                                                                            |
+------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER ON *.* TO 'backup'@'%' IDENTIFIED BY PASSWORD '*SOMETHING' |
+------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set …

当使用 SQL Server 2012 EMaintenance Plan 进行备份时，备份数据库任务会创建一个唯一的文件名。我理解格式一直到最后一组数字。

例如，通过备份数据库任务启动的完整数据库备份将创建如下文件名：

AdventureWorks_backup_2014_12_17_080005_5862824.bak

什么是5862824引用？是不是比LSN？还有什么？

我们将在明年第 1 季度迁移到 SQL Server 2014 昂贵版。现在我们使用的是 SQL Server 2005 标准版，因此我们无法访问MIRROR TO用于备份的非常棒的选项（我们使用 Ola Hallengren 的脚本）。

现在，我们正在使用 robocopy 将文件复制到网络共享，以防万一我们存储在本地的备份损坏、丢失或决定休个长假。我的问题是，当我们使用该MIRROR TO选项时，与仅使用 robocopy、xcopy 或 Powershell 解决方案相比，它是否会更多/更少地占用资源？当我们MIRROR TO在 SQL Server 中使用时到底发生了什么？如果可能的话，寻找一些“具体细节”的答案。

我有一个生产数据库，我通常每周运行一次完整备份。我为增量备份打开了 bin 日志。

生产服务器在西海岸，而营业时间在东海岸。

当我执行全备份时，我会查询主服务器的日志和位置。我将这些值放在我将数据库压缩到的 zip 文件名中。

我在使用 mysqlbinlog 从我知道备份已经结束的某个位置创建增量 sql 文件时遇到了困难。

运行Show Master Status然后运行mysqldump --flush-logs --single-transaction...就足以获得准确的信息以进行恢复。

我知道理想的设置是备份从属数据库，因为锁定不会损害生产环境，但目前我还没有进行切换。

因为我没有锁定所有表，所以我没有得到理想的结果吗？

提前致谢

编辑

在 RolandoMySQLDBA 的帮助下，我意识到我没有指向适当的 binlog 文件。我改为指向整个目录binlog/bin-log.[0-9]* > sql.txt。因此，仅使用该位置，我就可以击中比预期更早开始的日志。所以我更改了我的脚本以提取适当的 binlog 文件以及位置，这就像一个魅力。

谢谢

我在 Win 2012 服务器上安装了 postgreSQL 9.4.1。

我希望在这台服务器和另一台相同规格的服务器之间设置复制。因此，我按照热备份第 25.2.3 节中有关为备用服务器准备主数据库服务器的指南进行操作，这涉及使用pg_basebackup。

主服务器上的 PostgreSQL 实例包含我们的一个应用程序的数据库。该数据库有 3 个模式，每个模式都有自己的专用表空间。在 Windows 上，表空间位置是通过使用 MKLINK 命令创建的（因为我相信 LOCATION 参数必须指向 Windows 上的符号链接）所以 - 例如，：

mklink /j C:\tbs1 D:\app\tablespace\tbs1
mklink /j C:\tbs2 D:\app\tablespace\tbs2

因此，以上述为例，使用以下命令在 postgreSQL 中创建了一个表空间：

CREATE TABLESPACE app_ops OWNER the_user LOCATION 'C:\tbs1';

这一切都很好。但是，当我希望使用 pg_basebackup 工具时，我收到以下错误/警告 - 没有任何内容写入备份位置：

pg_basebackup -h localhost -U postgres -D C:\master_backup
pg_basebackup: directory "C:\tbs1" exists but is not empty

我不明白为什么我会收到这条特定的消息。

我看到的许多答案中的要点都是关于确保 PG_DATA 中不存在表空间。但是，在我的情况下，它们不是 - PG_DATA 在 Windows 服务的可执行路径中设置为-DC:\Program Files\PostgreSQL\9.4\data，如下所示：

"C:\Program Files\PostgreSQL\9.4\bin\pg_ctl.exe" …

我正在尝试做一些非常简单的事情，但有一个问题：

declare @cmd varchar(1000)

set @cmd='restore verifyonly from disk =''\\server\backup_folder\''?'''

exec sp_msforeachdb @cmd

显然它不起作用。我需要运行备份文件的名称Verifyonly（在上面的代码中，我使用的是数据库名称）。

有没有办法自动化Verifyonly，在所有备份文件中运行？

如何在我的代码中使用已创建的备份文件的名称？

非常感谢。

（人们MsForeachdb说不安全。我会尝试搜索另一个选项，例如Foreachdb）

SQL 服务器 2008

EDIT1：嗯，正如我在这里看到的，我认为这不是verifyonly一个好主意，但知道如何去做会很好（仅用于知识）

这是一个有助于我理解的理论问题。在sql server中从完全恢复模式切换到简单恢复模式的过程是什么？

是不是流程如下：

1. 在切换到 simple 之前进行 trans log 备份，以便我可以在切换之前进行时间点恢复。
2. 切换到简单。
3. 可能使用 TRUNCATE ONLY 运行 DBCC SHRINKFILE 以释放一些磁盘空间。
4. 可能更改数据库以减少 trans 日志文件的大小。
5. 执行完整备份。

我想我的主要问题是关于第 1 点。如果我不进行 trans log 备份，将 SIMPLE 丢弃最终 trans log 中的任何数据，或者切换到 SIMPLE 备份 trans log（我认为不会）。

此外，我认为最好的做法是在切换到 SIMPLE 后执行完整备份，以便可以在检查点将新事务从 trans 日志推送到数据文件。

我有一个带有 SQL Server 2014 的 Azure VM，带有一个用于存储备份的本地驱动器 (X:)。使用 Ola Hallengren 的脚本。我添加了 Azure 文件共享并尝试进行镜像备份，但出现以下错误：

BACKUP DATABASE [Test] TO DISK = 
    N'X:\Backup\SRVSQL01\Test\FULL\SRVSQL01_Test_FULL_20150420_185840.bak' 
MIRROR TO DISK = 
    N'\\storage.file.core.windows.net\backup\SRVSQL01\Test\FULL\SRVSQL01_Test_FULL_20150420_185840.bak' 
WITH NO_CHECKSUM, COMPRESSION, FORMAT

Msg 3212, Level 16, State 0, Line 3
The mirror device "X:\Backup\SRVSQL01\Test\FULL\SRVSQL01_Test_FULL_20150420_185840.bak" 
and the mirror device "\\storage.file.core.windows.net\backup\SRVSQL01\Test\FULL\SRVSQL01_Test_FULL_20150420_185840.bak" 
have different device specifications.

Msg 3013, Level 16, State 1, Line 3
BACKUP DATABASE is terminating abnormally.
Outcome: Failed

最初，本地驱动器被格式化为 64K 分配单元大小。尝试切换到 4K，并使用BlockSize开关，但没有运气。有任何想法吗？

我正在尝试将完整的数据库备份和事务日志还原到最新的事务日志。我已将交易日志设置为每 15 分钟发送一次。此设置是通过 SMSS GUI 执行的。完整数据库备份每天上午 12 点开始，通常在凌晨 2 点之前完成。

首先，我使用 NORECOVERY 恢复完整备份。：

USE [master]
RESTORE DATABASE [DBNAME] FROM  DISK = N'X:\path\to\DBNAME.bak' WITH  FILE = 1,  NORECOVERY,  NOUNLOAD,  REPLACE,  STATS = 5
GO

这将成功完成。

然后，我获取最旧的事务日志并运行以下命令：

RESTORE LOG DBNAME FROM DISK = 'X:\path\to\OldestTransactionLog.trn' WITH NORECOVERY;

但是，我收到以下错误：

Msg 4305, Level 16, State 1, Line 10
The log in this backup set begins at LSN 421814812000000025600001, which is too recent to apply to the database. An earlier log backup that includes LSN 421787067000000013800001 …

我有一个 SQL Server 2012 维护计划，它执行正常的操作（重建索引和更新统计信息、备份数据库、删除超过 X 天的 .bak 文件等）。除了一项维护清理任务外，一切正常：

这应该是删除所有意外留在每晚备份目录中的 .7z 档案（相当于 .zip 或 .rar）（尽管我们尽了最大努力，但最终还是有些人将这些文件留在服务器上......），但是E:\Backups\foo\bar.7z在维护计划运行后，子目录（例如）中仍然存在旧的 .7z 文件。

SQL Server 日志中没有错误。

我怀疑这是因为“删除以下类型的文件：备份文件”选项限制了可以删除的文件类型。我还尝试使用 7z 扩展名将其更改为“维护计划文本报告”，但没有任何更改。

是否可以让维护计划在维护清理任务期间删除任意（非 SQL Server）文件？如果是这样，知道我做错了什么吗？