White Papers

15 Dell PS Series Architecture: Self Encrypting Drive Management with PS Series Storage Arrays | TR1093
B Frequently Asked Questions
Why are my key backups always different?
Although the encryption key never changes, the backup will look different each time it is generated. The three
backup units are cryptographic images of the key, never generated the same way twice.
Why is there no secure-erase command?
None is needed. Whenever the array is reset, or when the situation warrants it (such as marking a failing drive
as failed or reusing a drive in a new array) AutoSED will perform a secure-erase, without intervention. There
is no need to perform a manual secure-erase, so there is no command to perform it.
Note: Secure-erase is also known as cryptographic erase or crypto-erase in the general SED literature on
the Internet.
What is the difference between a locked drive and a securely-erased drive?
Data that is locked is inaccessible without the SEDset Access Key. Data that is securely erased has been
cryptographically destroyed.
Are there any restrictions about mixing SED and Non-SED arrays in the same group or within a pool?
There is no restriction on mixing of SED and non-SED PS Series members in a group, or for that matter in a
pool. This means it is easy to deploy SED members without confusing restrictions, but it also means that you
don't necessarily gain the benefits of your SED members right away. In particular:
 In a mixed pool, volumes may be unencrypted, partly encrypted or completely encrypted, depending
on the PS Series arrays in the pool and the distribution of the volume slices among the available
resources.
 In a mixed pool, page movement does not pay attention to SED status. As a result, a page may move
from an SED member to a non-SED member, or vice versa, without notice.
 For more details, refer to Dell Storage PS Series Architecture: Load Balancers.
There will be a notice when adding a member to a pool changes that pool from homogeneous to mixed, but
this is only a notification, it does not block the action. If a pool is entirely SED, that pool will be marked as
such in the UI, and all volumes assigned to that pool will also be marked. If a pool is not entirely SED (either
mixed, or not SED at all) then the pool will not be marked and neither will the volumes in the pool.
Similarly, there is no restriction on mixing SED and non-SED groups and pools in replication. As a result,
even if a pool is entirely SED (and therefore the volumes in it are definitely all encrypted) those volumes may
be replicated to a partner that has no SED members, or a mix.
I accidentally removed an SED array from a group. Is there anything that can be done?