备份：
第一步、在数据库上点击右键，弹出菜单中选“所有任务”->“备份数据库”。
第二步、在弹出菜单中，选择要备份的数据库。
“数据库－完全”表示将数据库完全备份下来。
“数据库－差异”表示备份自上次完整数据库备份之后修改过的所有页。
“追加到媒体”，如果备份目的已经存在，则将这次的备份的内容跟在后面，就如同CD一样，一张CD可以放多首歌曲。
“重写现有媒体”雷同于拷贝文件时的“覆盖文件”。
第三步、在第二步中点击“添加”弹出如下对话框，我们可以直接输入要保存的文件名，也可以使用备份设备，备份设备就相当于一个别名，实际上与直接输入文件名是一样的结果。一路确认下去就可以了。
还原：
在还原对话框中，输入数据库名，实际中我发现有些人在还原数据库时，先建一个空白数据库，再在此数据库上强制还原。其实是没有必要的，在“还原为数据库”可以直接输入新的数据库名。还原一项中，如果我们没有备份集，我们就使用“从设备”还原。
数据库备份与还原－T-SQL
SQL Server的BACKUP DATABASE和BACKUP LOG语句参数非常的多，具体请参见SQL Server联机丛书，这里我们只以一个简单的例子介绍其基本用法。
sp_addumpdevice的三个参数分别表示，设备类型、设备逻辑名称和设备物理名称。
backup database将foo数据库备份到设备devicename，注意没有引号（如果数据库名称以数字开头，请加上“[]”）。
restore database从设备中还原数据库。
sp_dropdevice除去设备。
exec sp_addumpdevice ’disk’, ’devicename’, ’D:\db.bak’
backup database foo to devicename --备份
restore database foo from devicename --还原
exec sp_dropdevice ’devicename’
删除数据时漏写了WHERE，如何恢复？
要实现误操作恢复，恢复模型不能是“简单”恢复模型，至少是“大容量日志记录”恢复模型，最保险的是“完全”恢复模型（为什么要保险一些，请参见）。另外操作最好在查询分析器里操作，如果使用企业管理器，并且仅有一个事务日志，可能无法正确返回到即时点。
假如你在09:30:00时，删除某个表中的某条记录时忘记写WHERE，结果，所有的记录都已经被删除。幸好你在今天09:00:00对数据库进行了完整备份，并且恢复模型是“完全”恢复模型。这时你要做的是立即禁止他人对数据库的访问，并且备份事务。然后再利用以下语句还原。
restore database f2 from disk=’E:\foo’ with file=1, move ’foo_data’ to ’D:\foo_data.mdf’, move ’foo_log’ to ’D:\foo_log.ldf’, norecovery, replace
restore log f2 from disk=’E:\foo’ with file=2, stopat=’2005-12-18 09:29:59’, replace
并于restore的更多语法我们不在这里讨论，我们只说要注意的有两点，第一个还原语句要指明norecovery，表示还原操作不回滚任何未提交的事务，第二个还原语句stop表示还原到这个时间点时的数据库状态（这个点被称为即时点）。
执行上述语句后，我们现在的数据库就是和09:29:59的状态一样了。不过为了数据库的完整性，这之后对数据库的其它修改是无法恢复了，也就是说这之后对数据库的正确操作必须重做。
SQL Server非正常删除日志文件（ldf）恢复方法
事务日志文件(ldf)在SQL Server服务未启动的情况下被删除（SQL Server在工作状态下是无法删除日志文件），这种情况下启动SQL服务后，相应数据库即被标志成置疑(suspend)状态
按目前本人实验结果，恢复方法如下：
1，分离被置疑的数据库，可以使用sp_detach_db
2，附加数据库，可以使用sp_attach_single_file_db
SQL2K下可以直接在EM环境下完成这些操作，如果是SQL7则需要在QA里完成操作。
本人在SQL Server2000下实验数次均成功
若有哪位试了不成功的，请告知详细步骤及出错信息以方便再次实验，更好地解决。
以上方法适用于被删除日志文件中不存在活动日志的情况，如果有活动事务，将不会成功。
如何恢复系统数据库
关于系统数据库的恢复总结如下:
在SQL Server数据库中，系统信息存储在系统数据库中，主要的系统数据库包括：
master-从整体上控制用户数据库和SQL Server操作，在创建了任何用户定义的对象后，都要备份它
model-为新数据库提供模版和原型
msdb-包含了有关作业、报警及操作
员等信息如果包含系统数据库的介质变了，那么必须重建系统数据库，如果你仍然可以启动SQL Server服务，则可以通过RESTORE语句从系统数据库的备份中恢复数据库。
如果master坏了，不能启动系统,可以按照下面步骤进行恢复
1 重建系统数据库 运行c:\mssql7\binn\rebuildm.exe，按照提示进行即可，过
程中需要系统数据库样本的路径，可在安装光盘中找到；
2 重建系统数据库后，启动SQL Server服务，用系统数据库的备份恢复数据库就
行了通常恢复顺序为master->msdb->model
在恢复master的备份时要注意：必须在single user模式下进行，有以下几种方法
进入单用户模式：
1 可以在命令行模式下输入sqlservr -c -f -m或者输入sqlservr -m
其中：-c 可以缩短启动时间，SQL Server 不作为Windows NT的服务启动
-f 用最小配置启动SQL Server
-m 单用户模式启动SQL Server
2 可以在控制面板-服务-MSSQLServer的启动参数中输入-c -f -m或者输入-m,点
击开始
3 还有一种更灵活的启动方法：用存在注册表里的启动参数启动
在MSSQLServer项下添加项SingleUser,具体内容如下所示：
HKEY_LOCAL_MACHINE
\Software
\Microsoft
\MSSQLServer
\SingleUser
\Parameters
SQLArg0 : REG_SZ : -dC:\MSSQL7\DATA\MASTER.DAT
SQLArg1 : REG_SZ : -eC:\MSSQL7\LOG\ERRORLOG
SQLArg2 : REG_SZ : -lC:\MSSQL7\DATA\MASTLOG.DAT
SQLArg3 : REG_SZ : -m
在命令行下输入SQLServr -c -sSingleUser,注意：必须是在命令行下进入单用户模式后启动 Query Analyzer执行语句：
RESTORE DATABASE master form disk=’c:\(具体的备份文件名）
当SQL Server数据库崩溃时如何恢复？
任何数据库系统都无法避免崩溃的状况，即使你使用了Clustered，双机热备……仍然无法完全根除系统中的单点故障，何况对于大部分用户来说，无法承受这样昂贵的硬件投资。所以，在系统崩溃的时候，如何恢复原有的宝贵数据就成为一个极其重要的问题了。
在恢复的时候，最理想的情况就是你的数据文件和日志文件都完好无损了，这样只需要sp_attach_db，把数据文件附加到新的数据库上即可，或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行，不过一般不推荐这样的做法，sp_attach_db比较好，虽然麻烦许多。
但是呢，一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏页等写入磁盘的，这样的情况sp_attach_db就会失败。那么，寄期望于DBA制定了一个良好的灾难恢复计划吧。按照你的恢复计划，还原最新的完全备份，增量备份或者事务日志备份，然后如果你的活动事务日志还能读得出来的话，恭喜你！你可以还原到崩溃前的状态。
一般的单位都是没有专职的DBA的，如果没有可用的备份，更可能是最近一次备份的时间过于久远而导致不可接受的数据损失，而且你的活动事务日志也处于不可用的状态，那就是最麻烦的情况了。
不幸的很的是，一般数据库崩溃都是由于存储子系统引起的，而这样的情况是几乎不可能有可用的日志用于恢复的。
那么就只好试一下这些方案了。当然，是要求至少你的数据文件是存在的，要是数据文件、日志文件和备份都没有了的话，别找我，你可以到楼顶上去唱“神啊，救救我吧”。
首先，你可以试一下sp_attach_single_file_db，试着恢复一下你的数据文件，虽然能恢复的可能性不大，不过假如这个数据库刚好执行了一个checkpoint的话，还是有可能成功的。
如果你没有好到有摸彩票的手气，最重要的数据库没有像你期盼的那样attach上去，不要气馁，还是有别的方案的。
我们可以试着重新建立一个log，先把数据库设置为emergency mode，sysdatabases的status为32768 就表示数据库处于此状态。
不过系统表是不能随便改的，设置一下先
Use Master
Go
sp_configure ’allow updates’, 1
reconfigure with override
Go
然后
update sysdatabases set status = 32768 where name = ’’
现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。如果没有报告什么错误，现在就可以松一口气了。
虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损坏。
先把SQL Server 重新启动一下，然后检查你的数据库吧。
先设置成单用户模式，然后做dbcc
sp_dboption ’’, ’single user’, ’true’
DBCC CHECKDB(’’)
如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉。
update sysdatabases set status = 28 where name = ’’ --当然你的数据库状态可能不是这个，自己改为合适的值吧。也可以用sp_resetstatus
go
sp_configure ’allow updates’, 0
reconfigure with override
Go
checkdb的时候可能报告有一些错误，这些错误的数据你可能就只好丢弃了。
checkdb有几种修复选项，自己看着用吧，不过最后你可能还是得用REPAIR_ALLOW_DATA_LOSS，完成所有修复。
chekcdb并不能完成所有的修复，我们需要更进一步的修复，用DBCC CHECKTABLE对每一个表做检查吧。
表的列表可以用sysobjects里面得到，把OBJECTPROPERTY是IsTable的全部找出来检查一下吧，这样能够基本上解决问题了，如果还报告错误，试着把数据select into到另一张表检查一下。
这些都做完了之后，把所有索引、视图、存储过程、触发器等重新建立一下。DBCC DBREINDEX也许可以帮你一些忙。
然后，就可以向boss吹嘘一下你的丰功伟业，顺便小小的提一下加薪的要求，如果（很有可能）不得逞的话，也只好回家睡觉去:’(
记得下次别忘了做好备份哦~
上面提到的命令、对象在Books Online中均有详细说明，请注意参看。
来源:网络