Changing the DAOS tier 2 configuration

Table 1. DAOS tier 2 configuration changes
Setting	Recommendations for changing
DAOS Tier 2	To disable Tier 2, follow the steps in "Reverting Use of Tier 2 Storage". If you disable this setting and databases still reference objects stored in tier 2, Domino may be able to access those objects, provided that the remainder of the tier 2 storage configuration is intact. However, no new attachments are stored in tier 2. Also, DAOS may function unpredictably, for example show additional warning messages.
S3 Credential Name	Do not change the S3 credential name once it is established. It references a credential store entry which provides an access key ID and a secret access key to the S3 store you are using for tier 2.
S3 Bucket	All of a server's tier 2 objects are stored in a single bucket. Once objects have been stored in tier 2, do not change to a different bucket. If you do, Domino can't access any objects that were stored in the original bucket. A client that tries to access a tier 2 attachment will get an error such as `File does not exist`. If need to change the bucket, follow the steps in "Reverting use of tier 2 Storage", change the bucket name, then re-enable tier 2.
S3 Endpoint	In general, you should not change the S3 endpoint once it is established. However, if your S3 vendor provides you with a different endpoint that can access the existing S3 bucket, it should be possible to use that new endpoint.
Assigned S3 Storage ID	The S3 storage ID is a unique identifier for the server that is created the first time the server configures itself for tier 2. This ID becomes part of the name of each object stored in tier 2. You should not change this ID once it is established. (It is not an editable field in the server document.) As with the S3 bucket name, should you change this, Domino will not be able to access any objects that were stored using the original storage ID.
Push object to store if not accessed for N days	You can change this setting at any time. For an attachment to be pushed to tier 2, it must satisfy the normal DAOS requirement for minimum object size (thus already exist in tier 1), and it must also have not been accessed for the number of days specified by this setting. Since there may be a cost associated with downloading objects after they are pushed to S3 storage, set this to a value that is high enough to assure that a very small percentage of tier 2 objects are downloaded. In many applications, such as email, "older" attachments tend to be accessed infrequently. For more information on this setting, see Backup of DAOS tier 2 objects.
Push objects only between <time1> and <time2>	To minimize the impact on server performance, by default, the DAOSMgr task pushes attachment objects to tier 2 daily between 2AM and 5AM, a typical off-hours period. Objects that cannot be pushed within that interval become candidates to be pushed the next day. You can specify any interval that makes sense for your server. The interval can span midnight, for example, start at 10 PM in the evening and finish at to 2 AM the following morning.
Cached settings	To ensure that tier 2 operates correctly even if the server document is corrupted, Domino caches any changes to the tier 2 storage configuration in the following notes.ini variables. Do not delete or modify these settings. `DAOSTier2Enable DAOSTier2CredName DAOSTier2Bucket DAOSTier2Endpoint DAOSTier2ServerID DAOSTier2DaysToPush`

DAOS Tier 2

To disable Tier 2, follow the steps in "Reverting Use of Tier 2 Storage".

If you disable this setting and databases still reference objects stored in tier 2, Domino may be able to access those objects, provided that the remainder of the tier 2 storage configuration is intact. However, no new attachments are stored in tier 2. Also, DAOS may function unpredictably, for example show additional warning messages.

S3 Credential Name

Do not change the S3 credential name once it is established. It references a credential store entry which provides an access key ID and a secret access key to the S3 store you are using for tier 2.

S3 Bucket

All of a server's tier 2 objects are stored in a single bucket. Once objects have been stored in tier 2, do not change to a different bucket. If you do, Domino can't access any objects that were stored in the original bucket. A client that tries to access a tier 2 attachment will get an error such as File does not exist.

If need to change the bucket, follow the steps in "Reverting use of tier 2 Storage", change the bucket name, then re-enable tier 2.

S3 Endpoint

In general, you should not change the S3 endpoint once it is established. However, if your S3 vendor provides you with a different endpoint that can access the existing S3 bucket, it should be possible to use that new endpoint.

Assigned S3 Storage ID

The S3 storage ID is a unique identifier for the server that is created the first time the server configures itself for tier 2. This ID becomes part of the name of each object stored in tier 2. You should not change this ID once it is established. (It is not an editable field in the server document.) As with the S3 bucket name, should you change this, Domino will not be able to access any objects that were stored using the original storage ID.

Push object to store if not accessed for N days

You can change this setting at any time. For an attachment to be pushed to tier 2, it must satisfy the normal DAOS requirement for minimum object size (thus already exist in tier 1), and it must also have not been accessed for the number of days specified by this setting.

Since there may be a cost associated with downloading objects after they are pushed to S3 storage, set this to a value that is high enough to assure that a very small percentage of tier 2 objects are downloaded. In many applications, such as email, "older" attachments tend to be accessed infrequently. For more information on this setting, see Backup of DAOS tier 2 objects.

Push objects only between <time1> and <time2>

To minimize the impact on server performance, by default, the DAOSMgr task pushes attachment objects to tier 2 daily between 2AM and 5AM, a typical off-hours period. Objects that cannot be pushed within that interval become candidates to be pushed the next day. You can specify any interval that makes sense for your server. The interval can span midnight, for example, start at 10 PM in the evening and finish at to 2 AM the following morning.

Cached settings

To ensure that tier 2 operates correctly even if the server document is corrupted, Domino caches any changes to the tier 2 storage configuration in the following notes.ini variables. Do not delete or modify these settings.

DAOSTier2Enable
DAOSTier2CredName
DAOSTier2Bucket
DAOSTier2Endpoint
DAOSTier2ServerID
DAOSTier2DaysToPush