System Interfaces - return to top

What standard file system protocols does Permabit support? Why does this matter?
Permabit uses industry standard file sharing protocols to store and retrieve data. Users and applications access the underlying storage using CIFS, NFS and WebDAV. You can easily integrate Permabit managed storage with any application that supports these protocols, without modifying the application.

Microsoft Windows Compatibility - return to top

Does the Permabit System support access from Microsoft Windows?
The Permabit System supports the Common Internet Filesystem (CIFS) which is the file sharing mechanism supported by Microsoft Windows. Permabit volumes can be seen on the network as file shares from Windows-based servers.

Sharing Capacity Among Applications - return to top

Can I use one storage pool for multiple applications?
Multiple applications can be supported sharing the same storage pool.

Can I mix non-WORM and WORM volumes on this device simultaneously?
Yes, the Permabit software supports multiple volume types within the same device. The system provides:

1) Strict WORM volumes intended for regulatory compliance

2) WORM volumes with administrator-level volume deletion for corporate governance, and traditional read/write volumes.

Data Integrity - return to top

What is the MD5 hash problem?
In order to prove the integrity of a record, we use a “hash”, or “fingerprint” of the data. We verify the fingerprint of retrieved data against a fingerprint stored when the data was deposited. If the fingerprints match, we have proven that the data has not changed.

For this to work, we must be sure that an adversary cannot tamper with a record without changing its fingerprint. Otherwise, the adversary could change the stored record and the retrieved data would match the fingerprint, thus appearing authentic. A hash, or fingerprint, that cannot be compromised in this way is called a cryptographic hash. Use of a strong cryptographic hash is essential for record verifiability.

The MD5 hash was thought to be a strong cryptographic hash. But Wang et al. have discovered critical vulnerabilities in MD5 that render it so weak as to be unsuitable for use in a compliant record keeping system. Products that use the MD5 hash include older versions of EMC’s Centera.
For more information on this topic, see: X. Wang, D. Feng, X. Lai and H. Yu, Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD, Cryptology ePrint Archive, Report 2004/199, http://eprint.iacr.org, 2004.

Are Permabit systems subject to the MD5 hash problem?
No. Permabit uses a 256-bit hash key derived using the modern, more advanced SHA-256 algorithm. SHA-256 was developed in an open, international contest. It complies with federal standards (FIPS 180-2), and is ten billion billion (10,000,000,000,000,000,000) times less likely to cause a hash collision than the MD5 hash used in some versions of EMC's Centera™ and several back-up software offerings in in-line or post processing implementations.

Can there be SHA-256 Hash collisions in our system?
No. With SHA-256, the probability of a hash collision is truly astronomical. You would need around 2¹²⁸ different objects to have it be likely for this to occur, which would be about a 2800 trillion trillion petabyte repository. Basically, the probability of every hard drive in the system simultaneously crashing is much, much higher. For a more detailed look into this process, please view: www.snwonline.com/tech_edge/what_you_need_11-01-04.asp

Compliance – General Issues - return to top

How is WORM compliance achieved?
The Permabit software achieves compliance with WORM requirements by implementing all relevant operational and functional characteristics of WORM media:

• Reliability against hardware failures – no disk drive is permanently associated with any piece of data in the storage grid. If a drive fails, the data is re-replicated from the second copy.

• Reliability against data corruption – the integrity of data in the storage grid is constantly checked for data corruption by a background “scrubbing” process.

• Permanence – data cannot be deleted during the required retention period.

• Verifiability – data integrity is internally verified, and may be independently verified using Permabit Content Certificates.

• Security – only file system-level access is provided to the data. Such access is subject to access control. No one without physical access to the system may compromise data. Even someone with physical access to the system may only destroy data; not read it, nor falsify it.

• Shredding – Permabit allows destruction of data (analogous to “shredding”) after the required retention period has expired and the record has been deleted.

Note that in several respects, the Permabit system actually offers substantially enhanced functionality over traditional WORM systems. In particular:

• Native WORM systems do not generally have a background scrubbing process to guard against media errors

• Native WORM systems do not offer self-healing properties

• Native WORM systems do not generally offer content certificates for verifiability

• Native WORM systems usually support data destruction only on a per-media basis, not on a per-record basis

Can I store records generated by my legacy applications in a compliant fashion?
Yes. If an application is capable of reading records from a file system, those records may be migrated to a Permabit volume without any changes to the application. All the benefits of a Permabit system (permanence, reliability, security, verifiability, shredding, etc.) will apply to the migrated records. Permabit also offers the Retention Policy option, which enables retention policies that provide increased control over custom applications and user data. The Retention Policy option enables file-level retention policies based on a specified volume default or file type, user, or group. Once protected, files cannot be changed or deleted during the retention period. Even permanent file retention is allowed, subject to any limits configured for application-set retention.

Data Migration and Hardware End-Of-Life - return to top

Do you have a migration strategy that facilitates movement of data from one hardware platform to another?
Yes. Permabit solutions are designed to track with technology. The system supports online, automatic data migration, enabling the long-term preservation of electronic records. Data can be migrated to the newest technology without disruption to user or application access or forklift upgrades. New hardware platforms can be added to existing systems at any time.

Can the system incrementally take advantage of newer and faster components without replacing the entire platform?
Yes. The Permabit software's self-healing architecture supports:

• Expanding capacity by adding new servers

• Retiring old or failed hardware by removing old servers

The retirement process may be used to remove obsolete hardware (e.g. smaller disks, slower servers). Likewise, the expansion process may be used to add updated hardware (larger disks, faster servers). Both processes may be used sequentially to replace older hardware with newer hardware.

Is the hardware upgrade process disruptive?
No. Both the expansion and retirement processes are transparent to the application. There is no sacrifice of data availability, and very little (5-10%) impact on client peak performance.

Permabit ensures that, at all times, every object stored in the Permabit solution is available for access. The application need not know - and in fact cannot know - that data is being migrated around internally within the Permabit system.

Capacity Provisioning - return to top

How does the solution handle and manage logical volumes?
Dynamic capacity is allocated to file systems and volumes on an as-needed basis. There is no need to manage logical volumes - provisioning of storage in a Permabit system is automatic.

Can I expand a volume dynamically?
Yes. Automatic volume expansion is provided inherently and not required as an attended operation. Unused capacity is dynamically made available to all access nodes and file systems.

How is capacity increased?
Storage capacity is increased by adding new storage nodes to an existing Permabit system. Data is automatically re-distributed across all nodes in the storage grid. This is a non-disruptive process that does not require participation by vendor/partner service or support staff.

What logical and physical changes must I make to expand my capacity?
Simply rack a new storage node, connect it via dual ethernet cables, and add it through the Permabit Manager. Expansion and contraction of storage capacity is non-disruptive. Reads and writes can continue as capacity is added or removed.

Monitoring and Management

How do I monitor storage devices?
Permabit storage devices monitor the health of hardware and software components, take appropriate corrective actions (when possible) and notify administrative staff of issues found.

Can I monitor individual components?
Component monitoring is available via the Permabit Manager.

What do I need to administer the box?
The Permabit Manager supports Microsoft Internet Explorer Mozilla Firefox.

- return to top