前段时间折腾了一个 SQL Server 数据库异地备份解决方案，使用了一些不够完美不够和谐的方法完成了设计需求。昨天看到一款软件叫做 NcFTP，经过思考，有了下面的优化方案。

原先的方案需要在双方服务器上安置批处理并加入计划任务，他们之间的先后顺序是没有握手联系的，只能依靠时间来排序。最佳途径应该还是只在一台服务器上安置批处理。原先需要在备份服务器上通过 curl 来 pull 当天的备份，现在有了 NcFTP，我们可以让数据库服务器主动 push 备份文件到备份服务器上。

@set ftp_ip=0.0.0.0
@set ftp_port=1234
@set ftp_user=this_is_ftp_user
@set ftp_passwd=this_is_ftp_passwd
@set ncftp_path=C:/Program Files/NcFTP

"%ncftp_path%ncftpput.exe" -u %ftp_user% -p %ftp_passwd% -P %ftp_port% %ftp_ip%/tmp.rar 而删除备份服务器上的旧备份文件，也可以抛弃 Henry Xu 同学用 C++ 写的程序了，可以使用 Resource kit 里的命令 FORFILES。

- 阅读剩余部分 -

一直以来，公司某游戏平台使用 SQL Server 作为数据存储解决方案。为了数据的安全，每天凌晨在本机上做一次备份。但随着时间的推移，原先并没有设计到备份需求的硬件配置，尤其是外部存储这块，已经快不能满足 SQL Server 备份文件日益丰满的身姿。（这句话好像谁说过？）

为了彻底解决这个病痛，我打算为其实施远程异地备份。但查阅无数资料，均找不到较好的解决之道。大部分方案都是在备份目的地建共享目录，新增一个用户并赋权。然后在数据库端写个存储过程，添加数据库维护计划并使用这个存储过程。这样做有太多弊端：对于操作系统来说，很不安全；对于硬件架构设计来说，必须满足同一内网的条件。于是乎，放弃这样的方案。

经过几天的折腾测试，最后我采用了这样的方案。虽然比较老土，但至少 DIY 出来了，也暂时性满足了需求，缓解了阶级矛盾：

1、打开 SQL Server 企业管理器，找到数据库维护计划。

2、添加一个数据库维护计划，为其设置一个优美而和谐的名字，并选择需要操作的数据库对象。

- 阅读剩余部分 -

这是一句转折句：虽然十分不情愿，但本文档将在近期不断更新。

系统环境：Windows Server 2003 Enterprise SP2、SQL Server 2000

一、SQL Server 的连接方式

安装完成后默认两种连接方式：TCP/IP 与命名管道。就我个人的理解，前者适用各种网络环境，后者适用本机 ODBC 调用。由于调用 SQL Server 的服务端服务器与数据库服务器在同一机房、同一机柜、同一交换机中，我只使用 TCP/IP 作为唯一连接方式。

二、关于 SQL Server 的端口

SQL Server 默认监听 TCP/1433 端口，在服务端实用工具中设置数据库隐藏模式后将自动改变监听端口为 TCP/2433。隐藏模式使得客户端无法枚举数据库网络连接，也可以自行设定监听的端口，效果与设置隐藏模式雷同。

三、关于用户权限

我的个人建议是给 sa 加上一个一万年都无法暴力破解掉的密码，然后记录到某个密码管理软件里封存，然后从脑海中将这个密码忘记。关于密码管理软件，我也用过不少。目前习惯使用 Password Agent，虽然不是中文版本，但总比那些号称是“共享软件”的国产软件好。

不要使用 Windows 身份验证去访问数据库，忘记 sa 的存在之后，分别建几个用户用于管理相应的库，并赋予它们尽可能小的权限。权限不在大，只要够用就好。对于 db_owner，慎重赋予。一般而言，对于一个库的操作可以分开多个权限不同的用户，用于在不同场合执行不同的操作权限。

四、数据库维护计划

这是一项受人喜爱的功能。开启 SQL Agent 之后就可以在企业管理器中添加数据库维护计划。我习惯建立两种维护计划，一种用于对数据库进行优化，包括索引的重新整理以及对数据库数据文件与日志文件的容量收缩；一种用于对数据库数据与事务进行备份。

最近遇到一个磁盘空间瓶颈的问题，使得数据库备份只能限制在一周以内。打算采用 Windows 批处理、WinRAR 命令行加 FTP 命令的方式在设置的时间将本地数据库备份文件打包，并自动传送到另一台提供 FTP 服务的计算机上。为了避免网络带宽消耗甚至数据阻塞，建议在内网中进行该操作。