Skip to content

Working note Planning

Goal setting for storage and data projects

A storage decision is easier to defend when the goal is written before the product list. These four checks keep a project anchored to the service it has to deliver.

Start with the service, not the device

Write down what the application has to do and who depends on it. A backup target, a shared file service and an active archive look similar in a rack but have different recovery, access and retention requirements. The service description should name the data, the users, the access pattern and the consequence of an outage.

The data infrastructure primer is a useful map for this step because it separates compute, storage, networking and software rather than treating them as one purchase.

Separate capacity, protection and performance

Capacity is the easiest number to collect and the least useful on its own. Protection asks how many copies exist, where they live and how quickly they can be restored. Performance asks what the application needs at its busiest hour, not what a benchmark achieved on an empty system. Treat the three as separate goals so a decision in one area does not quietly weaken another.

This is the argument behind not everything is the same in the data center: availability, performance, cost and security have to be matched to the service being delivered.

Name the owner and the review date

A storage goal without an owner becomes a preference. Record who is accountable for the service, who approves changes and when the goal will be reviewed. A review date is especially important for retention and archive projects, where the original assumptions about data growth and access frequency are likely to change.

Test the exit before you commit

Ask how the data would leave the platform if the service were replaced. The answer should cover export formats, network time, egress cost and the readable state of the archive after migration. An exit plan written before the purchase is a useful test of whether the platform is being chosen for the right reason.

For object storage specifically, the fundamentals primer explains the vocabulary of buckets, namespaces and endpoints that an exit plan has to address.

A note on this page

This page continues a URL from an earlier version of the site. The original text was not connected to object storage, so it has been replaced with a short working note that fits the purpose of this center. The address is kept so old links continue to resolve.