Difference between revisions of "Retain Storage"
(→How Retain Determines File Uniqueness) |
|||
(2 intermediate revisions by one user not shown) | |||
Line 3: | Line 3: | ||
This is done a little like GroupWise, where the OFFILES directory stores Binary Large Objects (a.k.a., BLOBS - anything larger than 2KB). In the case of Retain, this is transparent to the user and you may choose whether to encrypt this data. If it is stored in a location accessible ONLY to the Retain Server, then encryption is not necessary and we recommend not using it. | This is done a little like GroupWise, where the OFFILES directory stores Binary Large Objects (a.k.a., BLOBS - anything larger than 2KB). In the case of Retain, this is transparent to the user and you may choose whether to encrypt this data. If it is stored in a location accessible ONLY to the Retain Server, then encryption is not necessary and we recommend not using it. | ||
− | == | + | ==Storage Concepts== |
− | + | ===SAN (vs NAS)=== | |
+ | SANs used fiber channel storage when first developed. It was faster than ethernet. That has changed recently since the advent of Fiber Ethernet (10 Gb/s and 40 Gb/s networks). | ||
+ | SANs have redundant disk controllers, NAS units do not. | ||
+ | SANs typically must use SAS drives, which can talk to multiple disk controllers. | ||
− | + | ===NAS=== | |
+ | Typically a Linux server with multiple drives (6, 8, 12, 24, etc. drive bays) | ||
+ | Redundant NICs | ||
+ | You can turn any computer into a NAS with open source software. | ||
+ | Uses NFS to connect to the drives (uses CIFs for Windows-based systems). | ||
+ | Client cannot see the different disks. The disks are presented as available “volumes”, which can span over multiple disks and typically do. | ||
+ | Typical RAID format is RAID5 or RAID10 (faster but requires double the disks). | ||
+ | Typically use SATA drives, which can NOT talk to multiple controllers. | ||
+ | They do not have multiple controllers. | ||
− | + | ===NAS iSCSI=== | |
+ | Fools the client OS into thinking it is talking to the hard drive. | ||
+ | You can format disks. | ||
+ | No faster than a standard NAS. | ||
+ | Only one iSCSI client gets to use it. | ||
− | + | ==How It Works== | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | == | + | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
=====How Retain Determines File Uniqueness===== | =====How Retain Determines File Uniqueness===== | ||
Retain creates a [http://en.wikipedia.org/wiki/Hash_function "hash"] off the message body and its attachments; however, it does not include the message metadata in the hash calculation; thus, a single BLOB on disk would be created for two messages that have identical message bodies and attachments but who date/time/recipients are different. In such cases, the database would get a new entry for each of those messages but only one file on disk would exist. | Retain creates a [http://en.wikipedia.org/wiki/Hash_function "hash"] off the message body and its attachments; however, it does not include the message metadata in the hash calculation; thus, a single BLOB on disk would be created for two messages that have identical message bodies and attachments but who date/time/recipients are different. In such cases, the database would get a new entry for each of those messages but only one file on disk would exist. |
Latest revision as of 21:13, 8 September 2017
Retain uses a hybrid storage system. All message headers and metadata is stored in the database but all message text and attachments are stored as files on the file system in the location listed here (and subdirectories).
This is done a little like GroupWise, where the OFFILES directory stores Binary Large Objects (a.k.a., BLOBS - anything larger than 2KB). In the case of Retain, this is transparent to the user and you may choose whether to encrypt this data. If it is stored in a location accessible ONLY to the Retain Server, then encryption is not necessary and we recommend not using it.
Contents |
[edit] Storage Concepts
[edit] SAN (vs NAS)
SANs used fiber channel storage when first developed. It was faster than ethernet. That has changed recently since the advent of Fiber Ethernet (10 Gb/s and 40 Gb/s networks). SANs have redundant disk controllers, NAS units do not. SANs typically must use SAS drives, which can talk to multiple disk controllers.
[edit] NAS
Typically a Linux server with multiple drives (6, 8, 12, 24, etc. drive bays) Redundant NICs You can turn any computer into a NAS with open source software. Uses NFS to connect to the drives (uses CIFs for Windows-based systems). Client cannot see the different disks. The disks are presented as available “volumes”, which can span over multiple disks and typically do. Typical RAID format is RAID5 or RAID10 (faster but requires double the disks). Typically use SATA drives, which can NOT talk to multiple controllers. They do not have multiple controllers.
[edit] NAS iSCSI
Fools the client OS into thinking it is talking to the hard drive. You can format disks. No faster than a standard NAS. Only one iSCSI client gets to use it.
[edit] How It Works
[edit] How Retain Determines File Uniqueness
Retain creates a "hash" off the message body and its attachments; however, it does not include the message metadata in the hash calculation; thus, a single BLOB on disk would be created for two messages that have identical message bodies and attachments but who date/time/recipients are different. In such cases, the database would get a new entry for each of those messages but only one file on disk would exist.
See KB, "Where Data is Stored in Retain" for more information.