(编辑：jimmy 日期: 2024/12/23 浏览：2)
1.全量数据备份
备份整个数据库，恢复时恢复所有。优点是简单，缺点是数据量太大，非常耗时
全数据库备份因为容易实施，被许多系统优先采用。在一天或一周中预定的时间进行全数据库备份使你不用动什么脑筋。使用这种类型的备份带来的问题是非常缺乏灵活性，而且当数据库被冲掉后，你面临丢失大量数据的潜在威胁。例如，假设你每天在午夜备份数据库。
如果服务器在晚上11点崩溃了，你将丢失前面23个小时对数据所做的全部修改。对大多数系统来说，这是无法接受的。对此规则，为数不多的例外如下：
1.系统中所存的数据可以很容易地再创建。这类服务器中一个很好的例子是报表服务器，其中所存的所有数据都由一个批处理过程装载的。如果这个数据库被冲掉了，你只需要再运行一次这个批处理过程，所有数据就可以恢复了。
2.不经常修改的数据库。一个例子是被收集存储在数据中心或数据仓库的历史数据。通常，查询这些数据以判断趋势，但是这些数据极少被修改。
3.一个遥远的站点，那里很少或没有数据库管理员支持。这种类型的站点常常依靠没受过足够培训的人来维持备份计划，并且他还从事其他工作。通常最好保证实施的备份计划非常简单，不必让那些用户监视和维护它。
4.系统中所存数据的重要性很低。一个很好的例子是开发用服务器。在这些类型的服务器上，开发者通常装载一些旧的或假定的数据来测试应用程序。这类数据库每天的备份是可接受的。
Sql语句：
BACKUP DATABASE [wxh] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\wxh.bak' WITH NOFORMAT, NOINIT, NAME = N'wxh-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
2.增量数据备份(Differential Backups)
所谓增量，就是以某个起始时间点的全量数据为基础，备份该时间点以后的数据。而起始时间点的全量数据，就是通过全量备份而为的。
如果有人告诉你“每周一进行全量备份，每天进行一次增量备份。”，这就意味着，星期一作一次全量配份，形成一个起始时间点的全量数据；星期二备份星期一以来的数据；星期三也备份星期一以来的数据；.......星期天也备份星期一以来的数据。到第二周的星期一时，又执行一次全量配份，再开始新的备份周期。
如果要恢复星期三的数据，则要先恢复星期一的全量数据，然后再恢复在星期一到星期三之间的增量数据。
增量备份是能用来帮助你实施备份计划的最新技术。这种备份，像事务日志备份一样，只备份你上次全数据库备份后所做的修改。与事务日志备份不一样的是这种备份不允许时间点恢复。它只允许你在实际所做的备份点上恢复。所以，这种备份通常要有事务日志备份作为补充。在下列情况下，增量备份非常有用：
1.你想通过联合使用全数据库备份、增量备份和事务日志备份最大程度地减少花费的时间。
2.数据库的大小使经常做全数据库备份很困难的情况。
3.一个遥远的站点，那里很少或没有数据库管理员支持。这种类型的站点常常依靠没受过足够培训的人来维持备份计划，而且他还经常从事其他工作。通常最好保证实施的备份计划非常简单，不必让那些用户监视和维护它。
4.系统中所存数据不是非常重要，所以所做的一些修改丢失后，不会导致灾难性的后果。对于这种类型的系统，手工重建数据比建立一个事务日志备份计划更容易。
Sql语句
BACKUP DATABASE [wxh] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\wxh.bak' WITH DIFFERENTIAL , NOFORMAT, NOINIT, NAME = N'wxh-Differential Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO
3.日志备份
周一做一次全量数据备份，周二时备份 周一至周二 的日志，周三时配份 周二至周三 的日志......。
若要恢复周三的数据，则先恢复到周一的全量数据，再按 周一至周二的日志、 周二至周三的日志 进行数据库操作
一个事务日志备份只备份事务日志中的信息。事务日志备份必须与至少一次全数据库备份联用，这是因为如果恢复数据，必须要有一个开始点。事务日志备份比全数据库备份少花费许多资源，经常执行也容易多了。这实际上有两个目的。首先是缩短了最后一次备份与服务器失败之间的时间间隔，因而减少了数据损失。事务日志备份还允许你实施一种特殊类型的恢复，即时间点恢复。这种类型的恢复允许你恢复数据到一个特定的时间点，比如到一次实际失败发生前5分钟时。
当某人所做的大量的数据修改或删除要取消时，它显得特别有用。你只需简单地恢复数据库到这次动作发生的时间点前。事务日志恢复在下列情况时非常有用：
1.数据库被高频率地修改。在发生大量的数据库修改时，数据库备份可能很快就过时了，如果把事务日志备份和全数据库备份联系起来使用，这些修改你都能记录下来。
2.你想采取时间点恢复。像我前面提到的，时间点恢复是非常重要和有用的，你可以通过事务日志备份来实现。
3.不能接受丢失大量数据的情况。在这种情况下，你可以每天做一个全数据库备份，再每小时或更频繁地做事务日志备份。这将减少数据丢失量。
4.数据库的大小使得经常做全数据库备份很困难。例如，非常大的数据仓库很容易达到上万亿字节。这种情况下，你可以做一次全数据库备份，然后当数据修改时，再做一次事务日志备份。
Sql语句：
BACKUP LOG [wxh] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\wxh.bak' WITH NOFORMAT, NOINIT, NAME = N'wxh-Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO
4.增量数据备份与日志备份相结合
sql语句：
备份整个数据库：
BACKUP DATABASE { database_name | @database_name_var }
TO < backup_device > [ ,...n ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]
[ [ , ] DESCRIPTION = { 'text' | @text_variable } ]
[ [ , ] DIFFERENTIAL ]
[ [ , ] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] FORMAT | NOFORMAT ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] MEDIADESCRIPTION = { 'text' | @text_variable } ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage ] ]
]
备份特定的文件或文件组：
BACKUP DATABASE { database_name | @database_name_var }
< file_or_filegroup > [ ,...n ]
TO < backup_device > [ ,...n ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]
[ [ , ] DESCRIPTION = { 'text' | @text_variable } ]
[ [ , ] DIFFERENTIAL ]
[ [ , ] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] FORMAT | NOFORMAT ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] MEDIADESCRIPTION = { 'text' | @text_variable } ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage ] ]
]
备份一个事务日志：
BACKUP LOG { database_name | @database_name_var }
{ TO < backup_device > [ ,...n ]
[ WITH
[ BLOCKSIZE = { blocksize | @blocksize_variable } ]
[ [ , ] DESCRIPTION = { 'text' | @text_variable } ]
[ [ ,] EXPIREDATE = { date | @date_var }
| RETAINDAYS = { days | @days_var } ]
[ [ , ] PASSWORD = { password | @password_variable } ]
[ [ , ] FORMAT | NOFORMAT ]
[ [ , ] { INIT | NOINIT } ]
[ [ , ] MEDIADESCRIPTION = { 'text' | @text_variable } ]
[ [ , ] MEDIANAME = { media_name | @media_name_variable } ]
[ [ , ] MEDIAPASSWORD = { mediapassword | @mediapassword_variable } ]
[ [ , ] NAME = { backup_set_name | @backup_set_name_var } ]
[ [ , ] NO_TRUNCATE ]
[ [ , ] { NORECOVERY | STANDBY = undo_file_name } ]
[ [ , ] { NOREWIND | REWIND } ]
[ [ , ] { NOSKIP | SKIP } ]
[ [ , ] { NOUNLOAD | UNLOAD } ]
[ [ , ] RESTART ]
[ [ , ] STATS [ = percentage ] ]
] }
< backup_device > ::=
{
{ logical_backup_device_name | @logical_backup_device_name_var }
|
{ DISK | TAPE } =
{ 'physical_backup_device_name' | @physical_backup_device_name_var }
} < file_or_filegroup > ::=
{
FILE = { logical_file_name | @logical_file_name_var }
|
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
}
截断事务日志：
BACKUP LOG { database_name | @database_name_var }
{ [ WITH
{ NO_LOG | TRUNCATE_ONLY } ] }
参数
DATABASE 指定一个完整的数据库备份。假如指定了一个文件和文件组的列表，那么仅有这些被指定的文件和文件组被备份。
说明 在进行完整数据库备份或差异数据库备份时，Microsoft® SQL Server"权限"部分。
FORMAT 指定应将媒体头写入用于此备份操作的所有卷。任何现有的媒体头都被重写。FORMAT 选项使整个媒体内容无效，并且忽略任何现有的内容。
重要 使用 FORMAT 要谨慎。格式化一个备份设备或媒体将使整个媒体集不可用。例如，如果初始化现有条带备份集中的单个磁带，则整个备份集都将变得不可用。
通过指定 FORMAT，备份操作也就暗示了 SKIP 和 INIT；这些都不必显式说明。
NOFORMAT 指定媒体头不应写入所有用于该备份操作的卷中，并且不要重写该备份设备除非指定了 INIT。
INIT 指定应重写所有备份集，但是保留媒体头。如果指定了 INIT，将重写那个设备上的所有现有的备份集数据。
当遇到以下几种情况之一时不重写备份媒体：
媒体上的备份设置没有全部过期。有关更多信息，请参见 EXPIREDATE 和 RETAINDAYS 选项。
如果 BACKUP 语句给出了备份集名，该备份集名与备份媒体上的名称不匹配。有关更多信息，请参见 NAME 子句。
使用 SKIP 选项替代这些检查。有关使用 SKIP、NOSKIP、INIT 和 NOINIT 时的相互作用关系的更多信息，请参见注释部分。
说明 如果备份媒体有密码保护，SQL Server 将不写入媒体，除非提供媒体密码。SKIP 选项不替代此检查。只有通过格式化才能重写受密码保护的媒体。有关更多信息，请参见 FORMAT 选项。
NOINIT 表示备份集将追加到指定的磁盘或磁带设备上，以保留现有的备份集。NOINIT 是默认设置。
RESTORE 命令的 FILE 选项用于在还原时选择适当的备份集。有关更多信息，请参见 RESTORE。
如果为媒体集定义了媒体密码，则必须提供密码。
MEDIADESCRIPTION = { text | @text_variable }
指明媒体集的自由格式文本描述，最多为 255 个字符。
MEDIADESCRIPTION = { text | @text_variable }
为整个备份媒体集指明媒体名，最多为 128 个字符。假如指定了 MEDIANAME，则它必须与以前指定的媒体名相匹配，该媒体名已存在于备份卷中。假如没有指定 MEDIANAME，或指定了 SKIP 选项，将不会对媒体名进行验证检查。
MEDIAPASSWORD = { mediapassword | @mediapassword_variable }
为媒体集设置密码。MEDIAPASSWORD 是一个字符串。
如果为媒体集定义了密码，则在该媒体集上创建备份集时必须提供此密码。另外，从该媒体集执行任何还原操作时也必须提供媒体密码。只有通过格式化才能重写受密码保护的媒体。有关更多信息，请参见 FORMAT 选项。
有关使用密码的更多信息，请参见"权限"部分。
NAME = { backup_set_name | @backup_set_var }
指定备份集的名称。名称最长可达 128 个字符。假如没有指定 NAME，它将为空。
NORECOVERY
只与 BACKUP LOG 一起使用。备份日志尾部并使数据库处于正在还原的状态。当将故障转移到辅助数据库或在 RESTORE 操作前保存日志尾部时，NORECOVERY 很有用。
STANDBY = undo_file_name
只与 BACKUP LOG 一起使用。备份日志尾部并使数据库处于只读或备用模式。撤消文件名指定了容纳回滚更改的存储，如果随后应用 RESTORE LOG 操作，则必须撤消这些回滚更改。
如果指定的撤消文件名不存在，SQL Server 将创建该文件。如果该文件已存在，则 SQL Server 将重写它。有关更多信息，请参见使用备用服务器。
NOREWIND
指定 SQL Server 在备份操作完成后使磁带保持打开。NOREWIND 意即 NOUNLOAD。SQL Server 将保留磁带驱动器的所有权，直到 BACKUP或 RESTORE 命令使用 REWIND 为止。
如果无意中使磁带处于打开状态，则释放磁带的最快方法是使用下面的 RESTORE 命令：
RESTORE LABELONLY FROM TAPE = <name> WITH REWIND
通过查询 master 数据库中的 sysopentapes 表可以查找正在打开的磁带列表。
REWIND
指定 SQL Server 将释放磁带和倒带。如果 NOREWIND 和 REWIND 均未指定，则默认设置为 REWIND。
NOSKIP
指示 BACKUP 语句在可以重写媒体上的所有备份集之前先检查它们的过期日期。
SKIP
禁用备份集过期和名称检查，这些检查一般由 BACKUP 语句执行以防重写备份集。有关更多信息，请参见注释部分。
NOUNLOAD
指定不在备份后从磁带驱动器中自动卸载磁带。设置始终为 NOUNLOAD，直到指定 UNLOAD 为止。该选项只用于磁带设备。
UNLOAD
指定在备份完成后自动倒带并卸载磁带。启动新用户会话时其默认设置为 UNLOAD。该设置一直保持到用户指定了 NOUNLOAD 时为止。该选项只用于磁带设备。
RESTART
指定 SQL Server 重新启动一个被中断的备份操作。因为 RESTART 选项在备份操作被中断处重新启动该操作，所以它节省了时间。若要重新启动一个特定的备份操作，请重复整个 BACKUP 语句并且加入 RESTART 选项。不一定非要使用 RESTART 选项，但是它可以节省时间。
重要 该选项只用于导向磁带媒体的备份和跨越了多个磁带卷的备份。在备份的第一卷上永远不会有重新启动操作。
STATS [= percentage]
每当另一个 percentage 结束时显示一条消息，它被用于测量进度。如果省略 percentage，SQL Server 将每完成 10 个百分点显示一条消息。
<file_or_filegroup>
指定包含在数据库备份中的文件或文件组的逻辑名。可以指定多个文件或文件组。
FILE = { logical_file_name | @logical_file_name_var }
给一个或多个包含在数据库备份中的文件命名。
FILEGROUP = { logical_filegroup_name | @logical_filegroup_name_var }
给一个或多个包含在数据库备份中的文件组命名。
说明 当数据库的大小和性能要求使得进行完整数据库备份不切实际时，备份一个文件。若要单独备份事务日志，请使用 BACKUP LOG。
重要 必须通过使用 BACKUP LOG 提供事务日志的单独备份，才能使用文件和文件组备份来恢复数据库。有关文件备份的更多信息，请参见备份使用文件备份。
如果恢复模型为 SIMPLE，则不允许文件和文件组备份。
n 是一个占位符，表示可以指定多个文件和文件组。对文件或文件组的最大个数没有限制。
LOG 指定只备份事务日志。该日志是从上一次成功执行了的 LOG 备份到当前日志的末尾。一旦备份日志，可能会截断复制或活动事务不再需要的空间。
说明 假如备份日志看来并没有截断大部分的日志，则有可能在日志中存在一个旧的开放事务。可以使用 DBCC SQLPERF (LOGSPACE) 观察日志空间。有关更多信息，请参见事务日志备份。
NO_LOG | TRUNCATE_ONLY
无须备份复制日志即删除不活动的日志部分，并且截断日志。该选项会释放空间。因为并不保存日志备份，所以没有必要指定备份设备。NO_LOG 和 TRUNCATE_ONLY 是同义的。
使用 NO_LOG 或 TRUNCATE_ONLY 备份日志后，记录在日志中的更改不可恢复。为了恢复，请立即执行 BACKUP DATABASE。
NO_TRUNCATE 允许在数据库损坏时备份日志。
注释
可以将数据库或日志备份追加到任何磁盘或磁带设备上，从而使得数据库和它的事务日志能存储在一个物理位置中。
当数据库正在使用时，SQL Server 使用一个联机备份过程来对数据库进行备份。下面的列表包括在数据库或事务日志备份时无法进行的操作：
在备份操作时允许进行文件管理操作，如带有 ADD FILE 或 REMOVE FILE 选项的 ALTER DATABASE 语句，以及 INSERT、UPDATE 或 DELETE 语句。
收缩数据库或文件。这包括自动收缩操作。
假如在这些操作正在进行时启动备份，备份将终止。假如正在进行备份时，试图进行这些操作，则操作会失败。
只要操作系统支持数据库的排序规则，就可以在不同的平台之间执行备份操作，即使这些平台使用不同的处理器类型。有关更多信息，请参见 SQL Server 排序规则基础知识。
备份文件格式
因为 SQL Server 2000 的备份格式遵从 Microsoft 磁带格式 (MTF)，该格式与 Windows NT 磁带备份所使用的格式相同，所以 SQL Server 备份可与 Windows NT 备份共存于磁带媒体上。若要确保相互操作性，磁带应由 NTBackup 格式化。
备份类型
SQL Server 支持的备份类型包括：
完整数据库备份，它备份包括事务日志的整个数据库。
在完整数据库备份之间执行差异数据库备份。
事务日志备份。
日志备份序列提供了连续的事务信息链，可支持从数据库、差异或文件备份中快速恢复。
文件和文件组备份。
当时间限制使得完整数据库备份不切实际时，请使用 BACKUP 备份数据库文件和文件组，而不是备份完整数据库。若要备份一个文件而不是整个数据库时，请合理安排步骤以确保数据库中所有的文件按规则备份。同时必须进行单独的事务日志备份。在恢复一个文件备份后，使用事务日志将文件内容前滚，使其与数据库其余部分一致。
在条带集中使用的备份设备必须一直在条带集中使用（除非在某处用 FORMAT 重新初始化），而且设备数目不变。在备份设备已定义为条带集的组成部分后，就不能用于单个设备备份，除非指定了 FORMAT。同样，一个含有非条带集备份的备份设备不能用于条带集，除非指定了 FORMAT。使用 FORMAT 来分开条带备份集。
如果写入媒体头时未指定 MEDIANAME 或 MEDIADESCRIPTION，则与空项对应的媒体头字段将为空。
如果恢复模型为 SIMPLE，则无法使用 BACKUP LOG。应该使用 BACKUP DATABASE 来替代。
SKIP、NOSKIP、INIT 和 NOINIT 间的相互作用
下表说明 { INIT | NOINIT }和{ NOSKIP | SKIP } 子句间是如何相互作用的。
说明 在所有这些交互操作中，如果磁带媒体为空或磁带备份文件不存在，则写入媒体头并继续。如果媒体头不为空或不含有效的媒体头，则指出这是无效的 MTF 媒体并取消备份。
INIT NOINIT
SKIP 如果卷中包含有效的1 媒体头，则验证媒体密码并重写媒体上的全部备份集，仅保留媒体头。
如果卷不含有效的媒体头，则使用给定的 MEDIANAME、MEDIAPASSWORD 和 MEDIADESCRIPTION（若有）生成媒体头。
如果卷中包含有效的媒体头，则验证媒体密码并添加备份集，并保留所有现有备份集。
如果卷不含有效的媒体头，则会出错。
NOSKIP 如果该卷包含一个有效的媒体头，将执行以下检查：
验证媒体密码。2
如果指定了 MEDIANAME，将验证所给的媒体名是否匹配媒体头的媒体名。
验证媒体上没有未过期的备份集。
如果有，将终止备份。
如果这些检查都通过了，将重写该媒体上一切备份集，只保留媒体头。
如果卷不含有效的媒体头，则使用给定的 MEDIANAME、MEDIAPASSWORD 和 MEDIADESCRIPTION（若有）生成媒体头。
如果该卷包含一个有效的媒体头，将验证媒体密码*并且验证媒体是否名匹配所给的 MEDIANAME（假如有的话）。如果匹配，追加备份集，同时保留所有现有的备份集。
如果卷不含有效的媒体头，则会出错。
1. 有效性包括 MTF 版本号和其它标题信息。如果不支持指定的版本或指定的版本不是期望值，将会发生错误。
2. 用户必须属于适当的固定数据库或服务器角色，并提供执行备份操作所需的正确媒体密码。
说明 为保持向后兼容性，在 BACKUP 语句的语法中可使用 DUMP 关键字替代 BACKUP 关键字。另外，可使用 TRANSACTION 关键字替代 LOG 关键字。
备份历史表
SQL Server 使用以下的备份历史表来跟踪备份活动：
backupfile
backupmediafamily
backupmediaset
backupset
执行 RESTORE 时，将修改备份历史记录表。
兼容性注意事项
注意 无法在早期 SQL Server 版本中还原使用 Microsoft® SQL Server™ 2000 创建的备份。
权限
BACKUP DATABASE 和 BACKUP LOG 权限默认情况下授予 sysadmin 固定服务器角色和 db_owner 及 db_backupoperator 固定数据库角色的成员。
此外，用户可以为媒体集、备份集或两者指定密码。如果为媒体集指定了密码，则用户若只是适当的固定服务器和数据库角色成员还不足以执行备份。用户还必须提供媒体密码才能执行这些操作。同样，除非在还原命令中指定正确的媒体集密码和备份集密码，否则不能执行还原操作。
在 BACKUP 语句中，定义备份集密码和媒体集密码为可选功能。使用密码可防止利用 SQL Server 2000 工具未经授权地执行还原操作和在媒体中添加备份集，但是，密码不能防止通过 FORMAT 选项重写媒体。
因此，尽管使用密码对防止利用 SQL Server 工具未经授权地访问媒体内容有帮助，但密码不能防止媒体内容被破坏。密码不能完全防止未经授权地访问媒体内容，原因在于备份集中的数据没有加密，理论上可以被专为此目的创建的程序所检查。对于安全性至关重要的场合，防止未经授权的个人访问媒体非常重要。
为不是用相关密码创建的对象指定密码是错误的做法。
BACKUP 使用由 PASSWORD 选项提供的备份集密码创建备份集。另外，BACKUP 正常情况下在写入媒体之前验证由 MEDIAPASSWORD 选项提供的媒体密码。BACKUP 不验证媒体密码的唯一情况是当格式化媒体时，这将重写媒体头。BACKUP 只在下列情况下格式化媒体：
如果指定了 FORMAT 选项。
如果媒体头无效且指定了 INIT。
如果正在写入延续卷。
如果 BACKUP 写入媒体头，BACKUP 将给 MEDIAPASSWORD 选项中指定的值指派媒体集密码。
有关密码对 SKIP、NOSKIP、INIT 和 NOINIT 选项的影响的更多信息，请参见注释部分。
备份设备物理文件的所有权和权限问题可能会妨碍备份操作。SQL Server 必须能够读取并写入设备；运行 SQL Server 服务的帐户必须有写入权限。但是，为设备在系统表中添加项目的 sp_addumpdevice 不检查文件访问权。备份设备物理文件的这些问题可能直到为备份或还原而访问物理资源时才会出现。
示例
A. 备份整个 MyNwind 数据库
说明 MyNwind 数据库仅用于演示。
下例创建用于存放 MyNwind 数据库完整备份的逻辑备份设备。
-- Create a logical backup device for the full MyNwind backup.
USE master
EXEC sp_addumpdevice 'disk', 'MyNwind_1',
DISK ='c:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\MyNwind_1.dat'
-- Back up the full MyNwind database.
BACKUP DATABASE MyNwind TO MyNwind_1
B. 备份数据库和日志
本例创建了一个数据库和日志的完整备份。将数据库备份到称为 MyNwind_2 的逻辑备份设备上，然后将日志备份到称为 MyNwindLog1 的逻辑备份设备上。
说明 创建逻辑备份设备需要一次完成。
-- Create the backup device for the full MyNwind backup.
USE master
EXEC sp_addumpdevice 'disk', 'MyNwind_2',
'c:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\MyNwind_2.dat'
--Create the log backup device.
USE master
EXEC sp_addumpdevice 'disk', 'MyNwindLog1',
'c:\Program Files\Microsoft SQL Server\MSSQL\BACKUP\MyNwindLog1.dat'
-- Back up the full MyNwind database.
BACKUP DATABASE MyNwind TO MyNwind_2
-- Update activity has occurred since the full database backup.
-- Back up the log of the MyNwind database.
BACKUP LOG MyNwind
TO MyNwindLog1
使用SQL产生BCP命令快速备份/恢复你所有数据（仅用于Sybase和MS SQL Server数据库)
BCP命令是Sybase和MS SQL Server用来备份和恢复数据用的工具，它使用方便，备份/恢复速度快。当Table过多时，编写批处理是一件繁琐的事情。可以使用下面方法快速生成BCP的批处理
select 'bcp database..' + name + ' out ' + '/data/' + name + '.out' + ' -n -Sservername -Usa -Pxxx' from database..sysobjects where type = 'U'
将上面database换成自己需要备份的数据库名称,-Sservername改为对应SQL Server名称 -Pxxx 将xxx换成实际sa密码，上面语法是用来备份数据，将第一行中的out改为in即可生成恢复数据的批处理 以上可以在Sybase或MS SQL Server的ISQL中执行(MS SQL Server 7.0中ISQL已变为Query Analyzer），然后将执行结果通过剪贴板Copy到记事本（注意不要Copy结果集的标题)，保存为Bat文件。在执行最后的Bat文件时，需要在Bat所在目录建立Data子目录，备份的*.out文件将存放在此子目录下。 也可以通过PB的Database Administration中执行(需要最后补充;号才可以执行)，然后将结果保存为Text类型，改名为Bat文件。