Redcurrant provides the following innovative features to answer client's business needs :

Grid storage

Thousands of servers are connected to each other, aggregating capabilities to provide a massive storage pool to client applications. There's no limit to the number of servers that can be used, nor the storage capacity and no Single Point Of Failure.

Object storage

Redcurrant is an object storage solution like the famous Amazon S3. Redcurrant is not a scalable POSIX filesystem that can be mounted from a Linux server. Application developers have the choice between a native object interface (C/JAVA/Python) and S3 REST API through a dedicated gateway (Feature planned in the Roadmap).

Vendor independence

The data logic (placement, security) is controlled in Redcurrant, thus avoiding any vendor lock-in. The API provides enough independance to allow a mix of any storage providers. See Storage policy below.


WORM stands for Write Once Read Many. With WORM mode activated, Redcurrant API forbids content alteration (append or delete) after their initial storage.


Redcurrant allows quota management at namespace, virtual namespace and container level. At namespace level, it will prevent Redcurrant from becoming physically full. At Virtual namespace, it allows usage partitioning. At container level, it allows even finer grain control.


Redcurrant allows versioning management. It means contents can be uploaded with the same name in the same container several time. For example, this is useful for office documents.

Storage Policy

Storage policy is the heart of Redcurrant storage engine. It relies on 3 main ideas:

  • storage devices are not equivalent and must be identified. This is the storage class.
  • data must be secured in different ways. Some are very important, some can be rebuild or re-uploaded. This is the data security layer.
  • data can be modified before going to disk (compression, cyphering). This is the data treatment layer.

Three mechanisms are available at the data security layer:

  1. NONE relies on the physical device security. Redcurrant will not duplicate chunk and data availability is guaranteed by the server availability and the RAID status.
  2. Duplication brings a higher level of security to the data at the expense of storage space. It implements one or more copies of all fragments of each content, and can be considered as a software RAID1. It allows the use of low cost storage.
  3. RAIN is a technology based on the 'Erasures code' that provides protection against simultaneous failures to disk, server and network level. Each chunk is split into k number of data subchunks and m number of coding (aka parity) subchunks. (k,m) is fully configurable by the admin and should be set according to business needs in term of extra space consumption / security of data. The more coding chunk, the more space used, the more security is provided.

Storage Engine is describe in a dedicated page

Data Deduplication

This feature avoids storing physically twice the same content, even with different name, and reduces space consumption.Deduplication happens at container level on a per container basis. Two identical contents in the same container can be deduplicated. Two identical contents in different containers can't be deduplicated.

S3 RESTful Gateway

This feature allows any S3 client to store data in a transparent manner into Redcurrant.


A snapshot is, like in photography, a state of a system at a given time. In Redcurrant context, a snapshot is applied to a container with a given label and date. It marks all contents of the current version with additional metadata with the corresponding snapshot label and date.

For more details, see the current release's documentation and the Redcurrant FAQ.

User Tools