可能有系统管理员会不解：为什么dp2系统不让用ISO2709格式来进行数据备份、恢复呢？
上面其实已经讲到了原因，这里再重复解释一下，细致分析一下。
ISO2709文件本身是一种书目数据的交换格式，并不是软件内部处理的格式。ISO2709记录的目次区等做法，完全是为了早期的通讯需要而设计的，可以看出这完全是一个“通讯交换格式”。
上面说到了，ISO2709记录所承载的MARC记录，MARC字段的使用也是有严格规范的，这些规范主要倾向于规定通用领域内字段名的可识别性、稳定性。因此，dp2系统要在里面扩充一些专用的字段，有不少困难。
从dt1000系统在MARC记录内扩充了-01字段并且(可选地)带到了ISO2709文件中，这一实践来看，效果并不好。有点强扭着ISO2709格式作为内部备份格式使用的意思。所以，dp2系统不想仿照这类不好的路线走下去。也可以说，正是dt1000的-01字段的用法带来的诸多缺点，让dp2系统决定不采用类似的做法了。
其实，开阔视野，系统内的备份格式，本来完全可以不用ISO2709格式。
dp2系统目前也可以输出ISO2709格式文件，甚至可以创建出符合dt1000要求的-01字段，但那是为了和其他系统交换数据用的，并不是自己的备份使用。有了这个划分，思路就清楚了，反而轻松了。
另外，dp2系统采用书目库和实体库等分置的系统结构，书目数据远远不够描述业务信息全部范围了(而dt1000是采用在书目记录中扩充字段来描述业务信息的)，今后将开发更多新的手段来进行备份，目前的利用多个单一库备份的做法仅仅是过渡。不过可以预料的是，将来更不会利用ISO2709格式来做备份的。
~~~
顺便谈到，目前，为了存储和表现Unicode字符集，ISO2709格式也进行了一些扩展，例如采用UTF-8编码方式的ISO2709文件。不过可惜的是，目前国内的许多开发商对这类应用还是一头雾水，给他们UTF-8编码的ISO2709文件，他们的系统无法处理这样的新鲜事物，转入到其本不能支持Unicode的系统中会乱作一团。
对dp2系统来说，由于它内核是Unicode字符集的，所以早已解决相关问题，应用中也倾向于(必须)使用UTF-8编码方式。但这只是dp2系统的情况，一枝独秀的情况。
而从外部看，从保守的角度，dp2系统的大部分用户在输出ISO2709文件给其他系统的时候，都主要采用国内常见的GB2312编码方式，缺点就是无法容纳Unicode字符了。
dp2系统不采用ISO2709作为备份格式，额外的好处就是避免了还要在导出的时候特意采用UTF-8编码方式的脑力负担。因为从ISO2709格式的角度，UTF-8编码方式是后来扩展的。而采用dp2系统的.xml和.dp2bak格式，Unicode类编码方式是天经地义的、缺省的，选都不让选就自动内定了。