网络同步备份系统的设计与实现毕业论文(编辑修改稿)

网络同步备份系统的设计与实现毕业论文(编辑修改稿)内容摘要：

有些 组织对 RPO 和 RTO 要求比较严格，为了能够在遇到灾难时以相对较短的时间恢复生产系统，组织会采用远程复制技术复制数据带灾难恢复位置。 而网络同步备份系统属于在线备份（热备份）可以快速恢复数据。 考虑到生产本地环境安全性原因， 通常 数据备份 一般存储在不同的介质 ， 最好是地理冗余避免因自然灾害（地震、火灾）而造成数据丢失。 在生产中心 存放一份从而 保证数据的 快速 恢复 ，系统正常运行；其他备份 则要移到 比较安全的地方 保存，以保证 当 生产中心 出现灾难后 以 最低 代价恢复 数据。 论文结构 第一章 绪论， 主要 对本课题的研究背景，现状， 研究的意义等 的介绍。 第二章 系统设计分析，主要阐述系统开发的可行性，以及对开发系统要使用的工具进行深入了解。 第三章 需求分析，对于本次毕业设计的具体需求情况进行分析，分别包括系统的数据分析，数据流程图等内容。 第四章 系统功能展示。 主要介绍系统各种功能的实现，同时列出关键代码。 第五章 系统测试与维护。 主要描述对备份系统各环节的测试和整个系统的测试 最后是结论和参考文献。 东华理工大学毕业设计（论文） 系统设计分析 4 2 系统设计分析 可行性分析 在 对整个网络同步备份 系统 进行需求 分析 时 ， 主要综合了技术可行性、经济合理性、系统实用性等各方 面。 以避 在研发和后期投入使用时出现故障 ，保证 备份 系统 成功开发。 可行性研究主要集中在以下三个方面： 技术可行性 通过对 系统的功能 分析 ，我们 使 用 Visual Studio 20xx 作为后台数据支持， 程序设计选择 C++程序设计语言进行程序编写， C++语言经过多年的发展和 更新 ，已经 成为一种非常稳定 的语言，因此本此课题研究在技术层面上，是完全可行的。 经济可能性 经济可能性主要是分析本系统在研发成本和投入使用后的运维费用上的投资。 同时对系统投入使用后的市场效益做评估。 确保收益大于投资，从而保 证整个项目能顺利完成。 本系统为企业的重要文件设计，通过使用本系统能够大大提高工作人员的效率，因此，本系统在经济上是可行的。 操作可能性 因为本系统采用的是 C/S 模型。 我们为客户开发了一个简洁大方的客服端界面作为系统入口，使用户操作起来简便。 软件程序开发是否能够取得成功，一是市场的需求，二是程序开发所需要软件开发工具，以及开发技术和当时硬件的发展水平。 从这两个方面而言，网络同步备份系统设计的操作性是可行的。 开发工具 Visual Studio 20xx 程序开发平台 Visual Studio 是微软公司推出的开发环境。 是目前 运用较为广泛 的应用程序开发环境。 Visual Studio 20xx 版本与之前版本有所不同的是重新设计和组织集成开发环境（ IDE）的界面，增加了 NET Framework 、 Microsoft Visual Studio 20xx 东华理工大学毕业设计（论文） 系统设计分析 5 CTP，并且支持开发面向 Windows 7 的应用程序。 在支持数据库方面加入了 IBM DB2 和 Oracle 数据库。 Windows 平台下 的 Windows 应用程序、智能设备应用程序 、 网络应用程序和 Office 插件 等都 可用 Visual Studio 创建。 于 1992 年发布 的 Microsoft C/C++ （ Visual C++） 与 原有 C++开发工具 Microsoft C/C++ 相比 ， 其 开创性地引进了 MFC(微软基础类库 )库 并 完善了源代码。 从此告别 了 DOS 的字符 界面，用户可以在 GUI 界面下进行开发， 开创了 软件开发 的 可视化 (Visual)时代。 从此，大佬的时代开始了。 C++程序设计语言 C++是 C 语言的 延伸，具有 面向对象编、泛型编程和过程化编程于一体的编程语言。 用 C++语言编写的软件稳定 性高。 C++与 C 语言最大的不同就是 C++引入了面向对象的概念，使得开发人机交互类型的应用程序更为简单、快捷， C++更简洁的说就是 C 的升级改造，在保持C 的简洁高效特点 同时 对 C 的 库 进行了扩充，因此 C++比 C 更安全。 很多优秀的程序框架 都是用 C++编写的，比较有名的有 Boost、 Qt、 MFC、 OWL、 wxWidgets、WTL。 东华理工大学毕业设计（论文） 系统设计分析 6 3 系统需求分析 需求分析 在 对整个网络同步备份 系统 进行需求 分析 时 ， 主要综合了技术可行性、经济合理性、系统实用性等各方面。 以避免 无意义的 投 资 ，保证 新系统成功开发。 需求分析主要是针对市场需求而对系统的各种功能进行分析， 可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。 对于本系统，分为客服端和服务器端两个模块。 在客户端用户可以注册、登录。 登录成功后，自动扫描本地目录，发现新文件或是文件更新自动同步到服务器。 定时比较服务器和本地目录的文件版本，自动下载最新文件。 当客户端不小心删除了本地文件可以从服务器端进行文件的下载。 服务器端对系统的需求包括：用户注册，并对登录的用户进行身份验证。 保留 客服端文件版本 的 信息， 提供客户端 文件的上传、下 载功能。 对用户的存储容量进行管理，当用户同步文件时超出了系统的存储能力，服务器将对用户发出警告。 经对整个系统操作流程的分析， 了解各层 模块 的功能需求，分析得出了本系统使用者的功能模块图，如图下所示： 网 络 同 步 备 份 系 统储 存 文 件发 送 到 服务 端意 外 删 除储 存从 服 务 端备 份 图 31 系统功能模块图 数据需求分析 通过对系统数据流的分析， 下图是用 数据字典描述 从客户端到网络同步备份系统到服务端 的 信息 流 、 数据 在 存储 系统中的存储 、 数据 处理过程和 模块 实体。 分析系统功能，绘制出系统数据流图，直观显示出系统数据在系统各个部 分之间的流动情况。 如图 32 描述，客服端触发事务（插入、修改、删除等）传输东华理工大学毕业设计（论文） 系统设计分析 7 到网络同步备份系统，存储系统对数据进行相应的修改并将操作结果发送到服务端。 服务端对数据也做相应的更新。 验证失败 验证成功 发现数据更新 本地数据更新 本地数据丢失 同步到服务 器 从服务器下载 数据存储 数据发送 图 32 数据流程图 存 储 系 统 登录客户端 与服务端比较 服务器 退出系统 验证用户信息 用户登录 东华理工大学毕业设计（论文） 系统设计分析 8 数据流图 在图 33 中，主要描述了整个系统的数据流图。 上行数据：用户成功登录后，网络同步备份系统从客户端接收信息，同时备份系统将从客户端接收的信息写入存储系统，服务器再通过备份系统接收来自客户端的数据。 下行数据：当服务端发现新版本的文件时，将发送信息给网络同步备份系统，备份系统将 更新的信息写入存储系统进行数据库更新，信息存储系统将更新的文件通过网络同步备份系统发送给客户端。 在整个数据流动过程中，信息储存是其核心。 不管是用户到服务端还是服务端到用户，其数据先经信息储存系统进行数据更新，再将更新后的数据发送给用户或服务端。 服 务 端网 络 同 步 备 份 系统接 收 信 息发 送 信 息信 息 储 存用 户 1用 户 2发 布 信 息接 收 信 息发 布 信 息接 收 信 息 图 33 数据流图 协议包基本格式 包格式 此处描述的是通过网络传递信息时用到的协议，为 IAP+TIP， TIP 协议为程序内部传输信息所 使东华理工大学毕业设计（论文） 系统设计分析 9 I A P 首 部 T I P 属 性C o d eV e rH d r l e nS e s s i o n i dT o t a l l e n g t hT I P 属 性r np r im o d er e s p a r m1 61 12 2111R e s e rv e d210 x E B 0 x 9 0 N U M1 1 1S r c A d d r D s t A d d r22s i dc i dc t mt i da b t L e nR e s e rv e rc o d e11 1 2 4 4 4 1 图 34 协议包图 IAP/IBP 包头 下面主要介绍 IAP/IBP 协议包头的各个参数，下图为 IAP/IBP 包头格式。 C o d eV e rH d r l e nS e s s i o n i dT o t a l l e n g t h1 1 2 2R e s e rv e d210 x E B 0 x 9 0 N U M1 1 1S r c A d d r D s t A d d r22 图 35 IAP/IBP 包头图 0XEB 和 0X90 字段 ： 这两个字节为同步头，为固定值，分别是 0xEB 和 0x90。 Header Length 字段 ： 包头数据长度为 1 个字节，即包头最长不 超过 256 字节 ， 为了找到属性的起始位置，必须从包头的开始位置偏移此长度就是属性的起始位置。 包头长度目前设计为 16 字节，但不排除将来为扩展协议而将包头的长度增加。 Ver 字段 ： Ver 字段表示当前协议的版本号。 目前的 版本号为 2。 Code 字段 ： Code 字段长度为 1 字节。 编码的取值范围是 0 到 255。 通过 Code，接收方可以区分不同的报文类型。 可以通俗地理解为需要这个包 做什么事，如请求，发送，应答等等，即 Code 表示一类动作指令，具有动词属性。 Reserved 字段 ： 保留字段，必要时候可以作为 Code 字段 的扩充，平时应该填 0。 Src Addr 字段 ： 报文源发送地址，指第一个目标产生此报文的程序的地址 Dst Addr 字段 ： 报文目的地址，指目标产生此报文的程序要发送给最终目的地址。 Num字段 ： Num字段长度为 2 字节。 编码的取值范围是 0 到 65535，表示发送包的序号，如果接收方需要对发送方的命令进行回复，那么回复报文中需要把接收方的 Num值拷贝到回复命令中进行回送。 Num值达到了 65535 后，自动东华理工大学毕业设计（论文） 系统设计分析 10 翻转到 0，并重新开始记录包序号。 Session ID 字段 ： 表示各模块之间进行交互， 2 字节，范围从 1－ 65535， 即最多同时有 65535 个会话，由各模块自己分配， Session id 在会话结束后回收，下一次可以重复分配使用。 客户端在收到来自服务端的响应后，须在返回的报文中 添加 这个来自服务端报文中的 Session ID。 0xFFFF 的 session id 是告警广播专用 id。 Total Length 字段 ： 2 字节 ， Total length 包括包头和属性的全部长度。 TIP 属性说明 TIP 协议作为程序内部传输的协议，在通过网络传递时，需要加上 IAP 头。 所有数据放在 TIP 的后面。 下面介绍 IAP 协 议包头的参数，包格式如下图： r np r im o d er e s p a r m1 11s i dc i dc t mt i da b t L e nR e s e rv e rc o d e11 1 2 4 4 4 1 图 36 TIP 包头图 Code 字段 ： 命令字字段。 Char 型字节。 Reserved 字段 ： 属于 保留 字段 ， 占 1 字节， 主要 用于 属性功能的 扩展 ， 目前填 0。 abtLen 字段 ： TIP 数据包的 长度，包括 TIP 包头和后面跟的所有数据。 Tid 字段 ： 前台系统分布在不同的地方，通过 tid 字段区分各个 站 点。 规定tid 字段为 9 位数，如 32302。