快速,持续,稳定,傻瓜式
支持Mysql,Sqlserver数据同步

SQL Server 2014备份基础

在线QQ客服:1922638

专业的SQL Server、MySQL数据库同步软件

SQL Server备份没有什么神秘之处。它们是必不可少的,但是您可以使用数据库。Grant Fritchey解释了使用SQL Server 2014进行数据库备份和还原的基础知识。

正确执行SQL Server备份是数据专业人员对其所从事的业务可以做的最重要的事情。不合适,丢失或未经测试的备份实际上可能导致整个业务失败。该问题使备份成为基本的业务问题,而不是技术问题。但是,解决业务问题的方法是通过技术手段,即SQL Server 2014提供的各种备份过程。

后备

备份只不过是在原始文件消失时作为一种保险单类型创建的副本。这在一定程度上适用于SQL Server数据库备份,但是数据库备份不仅仅是简单的文件副本。它们是一种非常特定的副本类型,它了解SQL Server的事务性质。该副本的创建方式将处理尚未完成的“进行中”交易。仅复制定义数据库的文件将无法处理事务,并且可能导致严重的数据损坏。因此,在大多数情况下,您应该使用本机备份过程或直接与本机过程配合使用的第三方工具,例如Red Gate SQL Backup。有些大型系统需要与非标准备份机制(如SAN快照)一起使用。这些远远超出了本文的范围。

本文介绍了大多数基本备份机制和一些更高级的备份机制。但是,数据库备份提出了一个非常复杂的主题。本文将确保您具有在系统上进行备份所需的信息,但是还有更多有关备份基础的SQL Server流程需要了解。

为了开始使用SQL Server备份,首先需要首先了解SQL Server提供的恢复模型。

恢复模型

SQL Server中的所有备份都受事务和事务日志管理的影响。事务日志管理的方法由数据库恢复模型控制。有三种:

简单:所有事务都写入日志。在检查点之后,所有已提交的事务都会自动从日志中删除,也称为截断日志。无法进行时间点恢复。

批量记录:除某些类型的最小记录操作(例如BULK INSERT和INSERT INTO)外,所有事务均写入日志。只能通过日志备份操作来截断日志。只要在任何必需的日志备份中没有最少记录的操作,就可以进行时间点恢复。

已满:所有事务均写入日志。只能通过日志备份操作来截断日志。时间点恢复是可能的。

虽然大容量日志记录恢复模型可以在某种程度上减小日志的大小,但它在时间点恢复上的局限性使其在大多数系统上的大多数数据库中不可行。绝大多数人使用简单或完全恢复模型。我将重点介绍本文中的两个主要模型。

业务需求决定了您是否需要完全恢复或简单恢复模型。您可能需要与企业一起定义恢复点目标(RPO)。RPO或多或少地定义了企业可以承受的信息丢失量。在简单恢复中,自上次完全备份或差异备份以来的所有数据都将丢失。这是因为日志在每个检查点之后都会被截断(这是一个自动过程,用于清理SQL Server中的内存和事务)。在完全恢复中,仅丢失自上次日志备份以来系统中的数据。甚至有可能通过运行所谓的尾日志备份来检索该数据(有关更多信息,请参见下面的“还原到时间点”部分)。

因此,首先要确定的是您要在相关数据库中为哪个RPO射击。如果数据不是那么重要的辅助系统,则简单恢复可以使您的备份和日志管理更加轻松。但是您必须记住,您放弃了还原到某个时间点的功能。对于大多数生产系统而言,数据对于企业而言至关重要,因此您应该计划完全恢复以及必要的计划日志备份。

简单恢复下的备份

要开始在简单恢复中使用数据库,我们需要先对其进行设置。我使用的是AdventureWorks2012,这是Microsoft提供的示例数据库(在此处可用)。为了确保它在简单恢复中,我可以运行以下T-SQL语句:

ALTER DATABASE AdventureWorks2012 SET RECOVERY SIMPLE;

这样会将数据库置于简单恢复中,并且该数据库不再具有还原到某个时间点的功能。

充分

要开始进行备份,可以发出以下T-SQL命令:

BACKUP DATABASE AdventureWorks2012

TO DISK = ‘D:\BU\AdventureWorks2012.bak’;

这将创建完整数据库的一页一页的副本,包括所有未提交的事务。备份中包括未提交的事务,以支持称为恢复的过程。恢复在还原过程中进行(有关更多详细信息,请参见下面的还原部分)。备份称为完全备份,因为它是数据库的全部,包括数据的每一位,所有结构和代码,甚至是数据库安全性信息。在指定的位置创建一个文件。最好备份到文件,然后将该文件复制到其他存储位置,例如异地位置或辅助介质,例如磁带(如果有人仍在使用磁带),因为这样可以使备份过程更快,更安全。您还可以执行更快的还原,因为您已将备份存储在磁盘上。

我使用T-SQL而不是图形用户界面有两个原因。首先,通过从T-SQL学习,您将更好地了解备份的工作原理,因为它可以将所有内容分解为最基本的基本命令,并且不像GUI那样杂乱无章。其次,当您开始在系统上构建备份过程时,将需要对其进行自动化和控制,并且可以通过T-SQL获得更好的自动化和控制选项,因此最好从头开始学习它。 。

微分

如果使用的是简单恢复,则可以进行常规备份。例如,如果您每周备份一次,则仍然有丢失多达一周的数据的风​​险。为避免这种情况,您可以在完整备份之间进行其他差异备份。差异备份是自上次完整备份以来数据库中所有已修改页面的副本,以及任何未提交的事务以进行恢复。最后一句话中最重要的部分是五个单词,“自上次完整备份以来”。让我解释一下。假设我们在周日晚上进行了完整备份。然后,在星期一晚上,我们进行差异备份。差异备份将包含自星期日以来一天以来已修改的所有页面。如果在星期二晚上再进行一次差异备份,其中将包含星期天以来两天的修改后的所有页面。顺其自然。

差异备份非常方便,因为它们可以实现更小,更快的备份。这意味着您在备份过程中将减轻系统负担。但是,它们会增加恢复数据库所需的时间,这将影响您的恢复时间目标(RTO)。那就是您还原数据库所花费的时间。随着您添加其他工作(例如,还原差异备份或在还原完整备份的基础上还原日志备份),该数字将增加。在制定业务备份策略时,必须考虑到RTO。

用于获取差异的T-SQL语法如下所示:

BACKUP DATABASE AdventureWorks2012

TO DISK = ‘D:\BU\AdventureWorks2012_Differential.bak’

WITH DIFFERENTIAL;

您会注意到,除了文件名的更改以及添加了WITH DIFFERENTIAL子句外,该语法看起来几乎与备份语法相同。WITH子句中有许多其他选项。在本文中,我们将仅介绍其中的一些内容。有关更多详细信息,我强烈建议使用联机丛书。

COPY_ONLY

差异备份带有潜在的障碍。它们表示当前数据库与上次执行完整备份时的区别。想象一下,您有一个预定的备份方案,在该方案中您将执行一次完整备份,然后进行两周的差异备份。显然,要进行还原,您需要该备份和最新的差异。但是,Tim,您相当粗略的同事,同时又进行了一次备份,以便复制数据库进行测试。这样做后,由于不再需要备份,他随后将其删除。然后,您的数据库崩溃并烧毁。您成功完成了完全还原,但是您的差异并没有使您保持最新状态,因为它代表了与Tim删除的备份的差异。相反,您会看到一个难看的错误。所以,

BACKUP DATABASE AdventureWorks2012

TO DISK = ‘D:\BU\ADW_Copy.bak’

WITH COPY_ONLY;

使用COPY_ONLY语句将确保此完整备份不会干扰后续的差异备份。

完全恢复下的备份

为了恢复到某个时间点,您必须能够执行日志备份。这意味着在完全恢复中具有数据库:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

现在,我不仅可以对该数据库进行日志备份,而且还需要对该数据库进行日志备份。

充分

当数据库处于完全恢复状态时,完全备份并没有真正改变。语法和结果相同。差异备份也是如此。他们不会改变自己的工作方式或方式。您只需要担心添加日志备份。

记录

对于处于完全恢复状态的数据库,如果不按计划运行日志备份,则日志文件将会增加。它会继续增长,直到填满放置它的驱动器为止。您必须运行常规日志备份。语法非常简单:

BACKUP LOG AdventureWorks2012

TO DISK = ‘D:\BU\AdventureWorks2012_Log.bak’;

这将备份AdventureWorks2012数据库的日志。注意,语法上唯一真正的变化是从单词DATABASE到LOG。这就是全部。这将复制日志中的所有事务(已提交或未提交)。然后,它将截断日志,这意味着将从日志中删除所有已提交的事务。这将释放日志中的空间用于更多事务。但是请注意,它绝对不会减少日志文件的大小。这只是为更多交易腾出空间。

此时,我们需要在备份中引入另一个概念。到目前为止,所有示例都显示了如何进行一次备份。但是,如果您要设置日志备份,则将进行很多备份。一个好的起点是每30分钟进行一次日志备份。一天当中有48个日志备份。如果将T-SQL语句再运行47次以上,则D:驱动器上只有一个名为AdventureWorks_Log.bak的文件。这是因为SQL Server会将备份附加到文件中,或多或少地将它们堆叠在一起。您可以通过选择要如何控制备份来控制此行为。您可以对一个文件执行所有操作,也可以转到多个文件。但是,如果您尝试对现有备份文件名执行备份,则SQL Server会将该备份堆叠在该文件中。要停止这种行为,

BACKUP LOG AdventureWorks2012

TO DISK = ‘D:\BU\AdventureWorks2012_Log.bak’

WITH INIT, FORMAT;

INIT关键字告诉备份过程中扔掉任何现有的备份,并与你正在运行这个新的备份初始化文件。但是,值得注意的是,如果您要再次运行此命令47次,您仍将只有一个文件,但仅具有最后一个日志备份。这可能是一个改变职业的问题。更新:Per Sean McCown,将FORMAT与INIT包括在一起始终是最佳做法,以避免头文件损坏而阻止成功备份。谢谢肖恩。

为了还原到某个时间点,您必须具有从恢复点开始的所有日志备份,这意味着要在连续链中还原完整备份或差异备份。您可以针对该数据库的任何完整备份还原给定数据库的日志备份,只要该备份在这些日志备份的时间范围内即可(使日志还原与差异还原完全不同)。但是,如果日志链中有一条中断,那么中断之后的所有日志备份都将无用:您丢失了该数据。

您有两种选择:您可以将备份堆叠到一个文件中,也可以将它们全部作为单独的文件。您的选择取决于您希望如何管理流程。您可以拥有一个文件,这使文件管理变得容易,但是要知道其中的内容更加困难(可以运行某些查询,我们将在“还原”部分中介绍它们),或者您可以知道备份中的内容,因为您可以命名会很小心,但是您将有更多备份文件要处理。我已经双向工作,都有缺点。通常,我选择将完整备份和差异备份保留为唯一文件,然后将日志备份堆叠到单个文件中。

您可以使用任何可以进行必要的T-SQL调用的计划工具来计划日志备份,但是最简单的方法是使用内置服务SQL Agent。

文件和文件组备份

对于非常大的数据库(也就是说,至少500gb,但更多的是5-10tb或更多),定期运行完整的完整备份可能会变得过于昂贵。因此,在需要时,您可以通过选择备份组成数据库的文件或文件组之一来选择备份较小的数据库。但是在开始备份文件和文件组之前,您需要考虑还原过程。之所以将其放入“完全恢复”部分是因为,在“简单恢复”下,您只能还原只读文件或文件组。您可以在完全恢复下还原文件或文件组,而与接下来将要讨论的数据库还原的其余部分无关,但是您必须具有完整的日志备份链才能还原读/写文件。

为了说明这一点,我将一个文件组和一个文件添加到AdventureWorks2012数据库中:

ALTER DATABASE AdventureWorks2012

ADD FILEGROUP SECONDFILEGROUP;

GO

ALTER DATABASE AdventureWorks2012

ADD FILE (NAME = N‘AdventureWorks2012_Data2’,

FILENAME = N‘D:\Data\AdventureWorks2012_Data2.ndf’,

SIZE = 2GB, FILEGROWTH = 10GB) TO FILEGROUP SECONDFILEGROUP;

GO

有了这个,我可以选择仅备份一个文件组:

BACKUP DATABASE AdventureWorks2012

FILEGROUP = ‘SECONDFILEGROUP’

TO DISK = ‘d:\bu\adw_fg.bak’;

现在,我可以独立于数据库的其余部分还原此文件组。有关从文件,文件组和部分备份恢复的更多信息,请阅读Sean McGeehee的这篇文章。

恢复数据库

保护您的业务的重要部分就是准备好备份。但是,正如我们所看到的,备份只是文件。还原意味着您再次拥有数据库。您只能以以前备份的方式还原以前备份的内容。我的意思是,如果您拥有完整的备份,仅此而已,您将无法执行差异备份或日志还原。此外,您无法选择性地还原该备份的零碎部分。例如,某人删除了一个存储过程,而您希望将其恢复。您不能仅备份并还原该过程。您需要像SQL Compare这样的工具来做到这一点。

为了还原数据库,不能建立任何连接。SQL Server中执行还原的进程必须具有独占访问权限。您需要使所有人(包括您自己)与数据库断开连接。一旦系统具有访问权限,还原就非常简单:

USE master;

go

RESTORE DATABASE AdventureWorks2012

FROM DISK = ‘d:\bu\AdventureWorks2012.bak’;

但是,如果我使用数据库的当前状态“完全恢复”来运行它,则可能会看到此错误:

Msg 3159, Level 16, State 1, Line 1

The tail of the log for the databaseAdventureWorks2012has not been backed up. Use BACKUP LOG WITH NORECOVERY to backup the log if it contains work you do not want to lose. Use the WITH REPLACE or WITH STOPAT clause of the RESTORE statement to just overwrite the contents of the log.

Msg 3013, Level 16, State 1, Line 1

RESTORE DATABASE is terminating abnormally.

这意味着我需要运行一种特殊类型的日志备份,即尾日志,这将在下一节中介绍。我可以选择忽略此错误并通过稍微修改我的还原命令来强制还原:

RESTORE DATABASE AdventureWorks2012

FROM DISK = ‘d:\bu\AdventureWorks2012.bak’

WITH REPLACE;

这将使数据库还原到我进行第一次备份时的时间点。您也可以选择完全将还原运行到另一个数据库名称,但是,由于数据库是一组文件,因此必须考虑到这一点,以避免产生错误并添加附加子句WITH MOVE:

RESTORE DATABASE AdwCopy

FROM DISK = ‘c:\bu\AdventureWorks2012.bak’

WITH MOVE ‘AdventureWorks2012_Data’ TO ‘c:\data\adwcopy_data.mdf’,

MOVE ‘AdventureWorks2012_Log’ TO ‘c:\data\adwcopy_log.ldf’;

MOVE语句使用逻辑文件名将它们移动到新的物理位置。这也是我第一次展示可以拥有多个WITH子句。您可以使用两个MOVE语句,用逗号将它们分开,数据库中每个文件一个。如果您不知道什么文件组成数据库,则可以使用另一个命令从备份文件本身中检索以下信息:

RESTORE FILELISTONLY

FROM DISK = ‘C:\BU\Adventureworks2012.bak’

这将显示逻辑文件名和已备份数据库的物理位置。您还将看到许多有关定义该数据库的文件的附加信息。

恢复到时间点

如果您不需要恢复到最新的数据,则可以使用完整备份和差异备份,而不必担心日志备份。但是,如果由于错误或其他原因而要恢复到最接近某个特定时间点的位置,则需要使用日志备份。要设置此测试,我们将运行以下脚本:

  • 确保我的数据库处于完全恢复状态
  • 进行完整备份
  • 然后进行编辑,修改数据
  • 然后进行日志备份以捕获该事务
  • 然后等待两分钟
  • 做另一个修改
  • 最后,我们还要进行另一个日志备份:

ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;

GO

BACKUP DATABASE AdventureWorks2012

TO DISK = ‘c:\bu\pit_full.bak’

WITH INIT;

GO

USE AdventureWorks2012;

GO

UPDATE Sales.Customer

SET ModifiedDate = GETUTCDATE()

WHERE CustomerID = 42;

GO

BACKUP LOG AdventureWorks2012

TO DISK = ‘c:\bu\pit_log.bak’

WITH init;

GO

WAITFOR DELAY ’00:02′

GO

UPDATE Sales.Customer

SET ModifiedDate = GETUTCDATE();

GO

BACKUP LOG AdventureWorks2012

TO DISK = ‘c:\bu\pit_log.bak’;

请注意,我的第二条UPDATE语句是一个巨大的错误。它没有WHERE子句,因此已修改了所有Sales.Customer行。我不想要那个,所以我要进行时间点还原。首先,我需要还原数据库,但是要保留完整还原的最后一步,即恢复,在此过程中,它会从备份开始前滚或后退任何打开的事务:

–just in case, backup the tail of the log

BACKUP LOG AdventureWorks2012

TO DISK = ‘c:\bu\pit_log_tail.bak’;

GO

USE master;

GO

RESTORE DATABASE AdventureWorks2012

FROM DISK = ‘c:\bu\pit_full.bak’

WITH REPLACE,

NORECOVERY;

为了预防起见,我继续备份了一次日志。因此,我不必使用WITH REPLACE选项,但是,作为预防措施,如果在我的RESTORE操作运行之前发生另一个事务,我将其放入。您可以通过运行查看数据库的状态此查询:

SELECT DATABASEPROPERTYEX(‘AdventureWorks2012’,‘STATUS’);

该数据库仍未恢复联机。

现在,我需要恢复我的日志,以便及时发现错误之前的时间点。所有进行的日志备份都保存在一个文件中,因此在运行该过程时,我需要确定该文件中要引用的备份。这是如何工作的。首先,我必须从适用于我的完整备份的日志以及感兴趣的时间点开始,因此,我将研究文件中的备份:

RESTORE HEADERONLY

FROM DISK = ‘c:\bu\pit_log.bak’;

就我而言,这仅返回两个备份,但是根据您如何设置备份过程,它可以返回任何数字。有了我需要参考的文件的知识,以及我希望停止的时间点的知识,就可以在出现错误之前,我可以像这样构建日志还原:

RESTORE LOG AdventureWorks2012

FROM DISK = ‘c:\bu\pit_log.bak’

WITH FILE = 1,

STOPAT = ‘2013-12-16 07:29:59.000’,

NORECOVERY;

我不得不在备份中引用文件,因为这次我选择将它们堆叠在一起。我还必须为日志提供STOPAT时间,以免意外运行,并且使数据库处于恢复状态,以便可以应用更多日志。这是下一条语句:

RESTORE LOG AdventureWorks2012

FROM DISK = ‘c:\bu\pit_log.bak’

WITH FILE = 2,

STOPAT = ‘2013-12-16 07:29:59.000’,

NORECOVERY;

我将继续恢复日志,增加文件的大小,直到我确定我找到的最后一个日志将使事务在我定义的时间结束。那我就停了 但是,数据库仍将无法恢复,因此我将不得不再做一步:

RESTORE DATABASE AdventureWorks2012

WITH RECOVERY;

这将使数据库处于最终恢复状态,使其联机到某个时间点。

备份到URL

SQL Server 2014的新颖之处在于,它允许您将Azure Blob存储与本地数据库关联使用。您可以直接备份到URL。这使您可以立即将备份保存在异地位置,以防丢失设备。这个过程很容易。首先,您必须设置一个Azure帐户,并在Azure上设置一个Blob存储帐户。设置完成后,其余的工作就很容易了。您需要从您的存储帐户中获取访问密钥,然后在SQL Server中创建一个凭据:

CREATE CREDENTIAL MyCredentialName

WITH IDENTITY = ‘MyStorageAccountName’,

SECRET = ‘MyAccessKey’;

您必须给凭据指定一个名称,然后使用您的存储帐户名称和访问密钥。设置好之后,只需对backup命令进行一些修改:

BACKUP DATABASE MyNewDB TO

URL = N‘http://myserver.blob.core.windows.net/bu/MyNewDB.bak’

WITH  CREDENTIAL = N‘MyCredentialName’,

NAME = N‘MyNewDB-Full Database Backup’,

STATS = 10;

除了向您展示如何使用URL代替磁盘并包括凭据之外,还添加了两个可以在备份上使用的WITH语句。您可以NAME备份,给他们更多的描述性的指示器,使其更容易理解为什么创建备份或者就是它的功能。当您运行RESTORE HEADER_ONLY命令时,此功能可用。您还可以通过添加STATS命令和以百分比为单位的增量来查看备份所花费的时间。当完整备份的每10%页面被复制时,将显示STATS = 10,使您可以了解备份运行时的状态。

相反,恢复是相同的事情:

RESTORE DATABASE AdventureWorks2012

FROM URL = N‘http://myserver.blob.core.windows.net/bu/MyNewDB.bak’

WITH  CREDENTIAL = N‘MyCredentialName’,

REPLACE;

当前,备份到Azure存储的文件限制为1TB或更少。您还需要在Azure存储上管理这些文件。我们可以为Cerebrata Azure Management Studio提供帮助。

数据库快照

数据库快照实际上并不是我们认为的备份,但是可以用来创建数据库的“副本”,然后从该副本还原,因此了解快照是什么以及快照的工作方式非常有用。快照备份是SQL Server 2005中引入的,可用于企业版SQL Server。创建快照时,将通过维护数据库页面的已修改副本(但仅保留那些已修改页面)的副本来创建数据库的只读副本。换句话说,在修改页面之前,页面将被复制到快照中。这使快照成为数据库的恒定副本,非常类似于备份。但是,它实际上不是备份,在大多数情况下也不应使用此机制来代替备份。我建议仅在需要对数据库进行短期备份的情况下使用它。例如,在生产升级期间,您可以拍摄快照而不是完整备份,以允许您从对数据库所做的更改中回滚。这是因为,一旦有了快照,您就可以将数据库实际上恢复为拍摄快照的状态。由于仅在已更改的页面中移动,因此快照的快照从根本上比备份数据库要快,恢复快照的过程也是如此。您实际上可以将数据库恢复为拍摄快照时的状态。由于仅在已更改的页面中移动,因此快照的快照从根本上比备份数据库要快,恢复快照的过程也是如此。您实际上可以将数据库恢复为拍摄快照时的状态。由于仅在已更改的页面中移动,因此快照的快照从根本上比备份数据库要快,恢复快照的过程也是如此。

创建快照所需的命令与我们一直在运行的备份命令完全不同:

CREATE DATABASE ADW_Snap

ON (NAME = AdventureWorks2012_Data,

FILENAME = ‘c:\data\ADW_Snap.ss’)

AS SNAPSHOT OF AdventureWorks2012;

我们实际上是在创建数据库。这是数据库的只读副本。您需要确保有足够的空间来存储页面,页面会随着基础数据库的修改而增长,但是它非常简单且快速。

您也可以“还原”这些。您将需要确保只有一个快照,因此,如果在数据库上创建多个快照,则需要删除除要还原的快照以外的所有快照。一旦完成,该过程将非常简单:

USE master;

GO

RESTORE DATABASE Adventureworks2012

FROM DATABASE_SNAPSHOT = ‘ADW_Snap’;

通过以与快照的原始创建相反的方式或多或少地进行工作,并沿另一方向复制的页面进行复制,将还原数据库。

最佳实践

数据库备份有许多“最佳实践”。我将只介绍一些最重要的内容。首先,我要重复很多次,数据库备份是企业应该定义的东西,而不是技术人员。与您的企业合作,确定确保您的信息受到保护的最佳方法。

您应该备份到存储数据和服务器操作系统的另一磁盘上。这有助于确保避免出现单个故障点。这就是为什么最好使用异地存储的原因,例如通过备份到URL或通过其他过程。如果您不必担心磁盘出现故障,那么您根本就不需要备份数据库。但是硬件确实会发生故障,因此请考虑到这一点。

绝大多数数据库在配置时都应考虑完全恢复。这意味着您将需要定期设置日志备份。频率确实取决于您可以与企业合作定义的恢复要求。

如您所见,设置和运行备份非常简单。没什么。但是,备份不过是存储在某处的文件。除非您可以恢复它,否则它是无用的。您必须确保可以还原的唯一最佳机制是实际还原它。这样,您不仅可以测试备份是否有效,还可以在需要时进行恢复过程中的练习。经常练习恢复。

最后,我在本文中使用了T-SQL来展示如何执行备份和还原。我这样做是因为您应该对所有备份使用脚本。这是因为脚本将使您能够最大程度地控制要备份的内容,如何备份,在何处进行备份等。为备份制定一个命名约定也是一个好主意,以便比较容易识别该文件代表什么。您可以将数据库名称,服务器名称甚至日期和时间合并到文件名中。这取决于您,但是在这些情况下,明确是您的朋友。脚本也将对此有所帮助。

有关备份最佳实践的更多信息,请阅读有关7可预防的备份错误的这篇文章。

摘要

这是对SQL Server 2014备份过程功能的概述。本文所涵盖的大部分内容在很大程度上适用于从编写到SQL Server 2000的所有过程。我试图确定何时引入了不同的功能,但是您总是可以参考您的SQL Server版本的联机丛书。请记住,备份主要是业务问题,而不是技术问题。为了制定一个好的备份策略,您必须与您的企业合作,以确保为他们提供足够的覆盖范围。不要忘记尽可能多地练习还原,尤其是在备份很复杂的情况下。管理备份并不难,但是正确无误至关重要。慢慢来。考虑一下您的策略。

相关推荐

咨询软件
 
QQ在线咨询
售前咨询热线
QQ1922638