数据库服务器备份方案方案一：完整备份+日志备份法(适合于数据量不是很大的时候，数据库文件小于20G)1. 每天0:00全库备份(数据文件首先备份在服务器上，然后可以将自动其拷贝到其他机器，也可以直接异机备份)。
2. 每天0:10起数据库日志备份（每30分钟备份一次，这个时间可根据公司业务需求作适当的调整）
3. 当服务器发生故障时，执行尾日志备份即可完全恢复。优点：硬件成本低；
缺点：恢复时间较长(恢复时间主要看数据文件的大小及生成的日志文件大小，20G的数据文件和日志文件约需60分钟)，
当尾日志备份备份不成功时，将丢失最后一次日志备份以来的所有数据
（即：最多将丢失故障前30分钟的数据，但因为服务器采用了RAID5的存储解决方案，丢失数据的可能性不大）方案二：完整备份+差异备份+日志备份(适合于数据量很大的时候，数据库文件超过20G)
1. 每星期日0:00全库备份(数据文件首先备份在服务器上，然后可以将自动其拷贝到其他机器，也可以直接异机备份)。
2. 每天（星期一到星期六）0:00差异备份，随后：每30分钟执行一次日志备份(这个时间可根据公司业务需求作适当的调整)。
3. 当服务器发生故障时，执行尾日志备份即可完全恢复。优点：硬件成本低，减少由于备份给服务器造成的压力。
缺点：恢复时间长(恢复时间主要看生成的日志量，80G数据文件约需120分钟)，
当尾日志备份备份不成功时，将丢失最后一次日志备份以来的所有数据
（即：最多将丢失故障前30分钟的数据，但因为服务器采用了RAID5的存储解决方案，丢失数据的可能性不大） 个人建议：为减少备份时的网络开销，避免由此造成资源瓶颈，建议在服务器本机加一硬盘用以备份，再适时将备份文件拷贝到其他服务器。若公司由于特殊业务需要每周7*24小时保持高可用性，建议采用数据库集群。但是：这样，将增大硬件成本。
2. 每天0:10起数据库日志备份（每30分钟备份一次，这个时间可根据公司业务需求作适当的调整）
3. 当服务器发生故障时，执行尾日志备份即可完全恢复。优点：硬件成本低；
缺点：恢复时间较长(恢复时间主要看数据文件的大小及生成的日志文件大小，20G的数据文件和日志文件约需60分钟)，
当尾日志备份备份不成功时，将丢失最后一次日志备份以来的所有数据
（即：最多将丢失故障前30分钟的数据，但因为服务器采用了RAID5的存储解决方案，丢失数据的可能性不大）方案二：完整备份+差异备份+日志备份(适合于数据量很大的时候，数据库文件超过20G)
1. 每星期日0:00全库备份(数据文件首先备份在服务器上，然后可以将自动其拷贝到其他机器，也可以直接异机备份)。
2. 每天（星期一到星期六）0:00差异备份，随后：每30分钟执行一次日志备份(这个时间可根据公司业务需求作适当的调整)。
3. 当服务器发生故障时，执行尾日志备份即可完全恢复。优点：硬件成本低，减少由于备份给服务器造成的压力。
缺点：恢复时间长(恢复时间主要看生成的日志量，80G数据文件约需120分钟)，
当尾日志备份备份不成功时，将丢失最后一次日志备份以来的所有数据
（即：最多将丢失故障前30分钟的数据，但因为服务器采用了RAID5的存储解决方案，丢失数据的可能性不大） 个人建议：为减少备份时的网络开销，避免由此造成资源瓶颈，建议在服务器本机加一硬盘用以备份，再适时将备份文件拷贝到其他服务器。若公司由于特殊业务需要每周7*24小时保持高可用性，建议采用数据库集群。但是：这样，将增大硬件成本。
我是写不出来的
我觉得你写的主要给谁看，如果专业人员的话当然没问题，如果给那些外行的人肯定就不懂了。。感觉还是很不错，很详细。。主要还是看你的用途。。