大部分企业数据库的数据流量在增长，却缺乏控制，甚至无法控制，而资金、电量和数据中心空间都是有限的资源，因此数据库对这些资源的利用率必须提 高。
供应商采用多种方式来提高其数据归档解决方案的效率。数据缩减技术如压缩、单一实例存储(single instance storage)和大部分功能强大的sub-file重复数据删除技术，这使得供应商可将30 lbs的数据装入10 lb的数据归档。在不使用Spinning disk时，将其关闭，无论供应商将其称为MAID (Copan, Nexsan)或是HDS，其可将1TB驱动器的能源消耗从7.5W减少至不到1W。
但即使这些驱动器都停止运行，MAID系统仍要消耗大于等于其正常运行时30%的电量，因为在低负载时，电力供给效率变低。处理器在处于空转状 态时仍有电力消耗，而空转存储器与一个采用最新级别EnergyStar的空转服务器处理器(消耗电量为55W)相比，也好不到哪去。
数据归档存储的最简系统，我称之为上锁的NAS(locked NAS)。供应商包括NetApp和Sun公司已经扩展了其文件系统和NAS操作系统以将保持执行力加进来。他们是仿效了NetApp公司对SnapLock的命名方式，将最新改进技术的日 期加到设备寿命的末尾，打上“只读”的旗号。这一系统将在寿命期结束时对只读部分进行重设。
Locked NAS是一般系统，但是缺乏上次我所提到的一些其他功能。
而NetApp文件编档员核查每个有众多杂乱信息的数据块的完整性，这并非在后台运作，在发现问题时也无法从远程获取一份已损坏的本地数据块的 完整版本。可测量性和长期扩展是问题所在，因为增加驱动器以及每5—7年进行一次数据转移(因为你企业的供应商或许将不再支持你的企业系统)并不是解决问 题的好方法。
基于磁盘的数据存储归档这一市场领域，另一竞争者是Content Addressable Storage，采用每个存储目标(文件，email信息等)的hash作为存储目标(而非文件位置)的重要标识符——同NAS系统。与通常思维不同，CAS系统不采用完整的文本索引作为其选址方案，而仅选用存储目标的hash。事实上，大部分CAS系统，包括 EMC公司的Centera、Nexsan公司的Assurion和Caringo公司的CAStor,都未给其存储内容编制索引。
他们在企业内部实施了单一实例存储(例如相同文件的多次拷贝将导致相同的冗余数据)，也检查了file hash，以整合后台数据。除了大部分文件系统支持的名称、所有者以及时间戳，大多数CAS系统也可存储扩展元数据。结果是，大多数有复杂的应用程序编程 接口被用于文件存储和恢复，这就要求数据归档软件供应商写入并测试界面。SNIA有标准的XML API——被称为XAM，将在一年后首先出现在CAS以及其他固定内容存储系统上。
CAS供应商很重视扩展元数据。ILM(当前仅仅是个构想，尚未有产品)的数据分类功能、e-discovery功能，及类似功能都需要除名称和日期外的其他数据，以进行决策。我存有疑问的是：需要存储 一个有API的特殊文件系统。数据归档软件或者内容管理系统仅能够将元数据和所有重要的文本索引完整地放入独立于文件系统的数据库。
一些供应商已经建造了类似NAS的设备，采用hash确保完整性及识别数据的唯一标识，而不将其作为目标数据的主要地址。类似Data Domain公司的设备和NEC公司的Hydrastor，都被作为备份目标，但从其特征看，与数据归档设备的水平差不多。Data Domain的设备可进行数据保存和去除，这与CAS的功能相同。Permabit公司的Enterprise Archive采用相似的hash来协助管理NAS数据。
很多此类系统采用RAIN(独立结点的冗余阵列)结构，这样一个有1u到2u服务器及内置存储器的群组或网格支持和管理分布在阵列中的数据。某 些系统采用吸收/修复结点，这些节点可管理hash 数据，并接收数据，同时存储支持数据结点。有些系统同时具有上述两方面功能。
如果得以完整实施，RAIN模式将使100个结点获得可测量性，新结点也可获得可测量性，处理器的速度更快，磁盘容量更大，且都将增加一个阵 列，曾经放置在旧的慢速结点或出现问题结点上的数据都将被重新安置，接着旧结点都将被少量点击或命令取代。然而，大部分RAIN系统有一个相关的高速处理 器，这会导致电力消耗的增加，同时可能会导致访问次数极少的大型数据归档消耗过多。
