How to review storage and capacity before scaling infrastructure

"The disk is at 90%, we need to buy more"

The alert arrives and the solution seems obvious. But before scaling, ask: did it reach 90% gradually or suddenly? What is occupying the space? How long must those data be kept? Scaling without answers can solve the symptom for a few months and then reappear at greater cost.

Four questions before scaling

Trend: look at weeks, not one day

Record usage weekly for at least a month. Steady growth allows you to estimate when you'll hit the limit. A jump usually has a cause: an import, a backup left on the server, error logs that grew. AWS guides on performance and reliability recommend monitoring usage to plan capacity rather than reacting.

Composition

Ask your technical team or provider to identify what is occupying space. Databases have tools for this: PostgreSQL documents how to determine disk usage, and MongoDB offers statistics for each database. It's common to find backups stored on the same server, logs without rotation, or temporary files.

Retention: decide, don't delete

Before deleting anything, define how long each type of data must be kept. Some data have legal or accounting retention obligations that your accountant or advisor must confirm. Others, such as old technical logs, can be archived or removed according to an agreed policy. Do not delete anything without review and a verified copy.

Capacity is not just disk

The same logic applies to memory, CPU and connections. If the site slows at certain hours, check whether it's a traffic spike, a scheduled job, or an expensive query. The Google SRE book covers how to handle overload; sometimes the solution is optimization or redistribution, and other times it is scaling.

Procedure

1. Record usage and limits weekly for one month.
2. Identify the composition of the space.
3. Define or confirm retention for each data type.
4. Estimate when you'll hit the limit given the current trend.
5. Evaluate options: optimize, archive, scale.
6. Test any change in a staging environment when possible.
7. Decide and document.

Applied example

Limits

This guide does not recommend deleting or buying without review. Growth estimates are approximations that change with the business.

How to use the downloadable log

1. One row per resource and week.
2. Record usage, limit and composition.
3. Note the agreed retention.
4. Decide after one month of trend.

Decision criteria

Full synthetic example

Synthetic example. The server of a fictitious company reaches 90% disk and the provider proposes doubling capacity. Before accepting, the company records usage for four weeks: it grows by about 2 GB per week.

On reviewing composition, it finds that 55% of the disk are backups stored on the same server for three years and 20% are application logs without rotation. Management defines a policy: daily backups retained 30 days and stored off-server, and logs rotated every 90 days. Before deleting anything, external backups are verified for restoration.

After applying the policy, usage drops to 45%. With measured growth, the company calculates it has more than a year of margin and decides to review again in six months. Example is illustrative.

Common mistakes, explained

Deleting to free space without an approved policy can remove data the company needed to retain for operational or legal reasons. And keeping backups on the same server they protect is useless if that server fails. Decide what to keep, for how long, and where, before deleting or buying.

How to know it worked

• You have at least one month of trend data.
• You know the composition of usage.
• Retention is approved in writing.

Plan for the first four weeks

1. Week 1: start weekly logging.
2. Week 2: identify composition.
3. Week 3: propose retention and validate external backups.
4. Week 4: decide to scale, clean up or optimize.

Diagnostic before starting

• Review current usage of disk, memory and CPU.
• Ask what retention policy exists.
• Identify what occupies the most space.

A second, contrasting example

Synthetic example. A fictitious company checks its server and sees disk at 40%, but the system is slow. The problem is memory, consumed by a reporting process. They optimize that process instead of scaling. Unlike the first example, the constrained resource was not disk. Example is illustrative.

What to do when something fails

• If the disk fills, free space safely (old logs already backed up) and then apply the policy.
• If you deleted something necessary, restore from backup.
• If scaling does not improve performance, review other resources.

How to measure it with your own data

• Record weekly usage of disk, memory and CPU.
• Note the average weekly growth over the last four weeks.
• Measure the space freed after applying retention.
• Check whether performance improved after each change.

With your own trend you can estimate how many weeks until you hit the limit. If after applying retention growth remains stable and performance is adequate, the decision was correct. If usage rises quickly again, check whether the policy is applied automatically or depends on someone remembering it.

Common mistakes

• Scaling without knowing what is using the space.
• Deleting data without a retention policy.
• Storing backups on the same server.
• Looking at a single day and not the trend.
• Ignoring memory, CPU and connections.

Checklist

• At least one month of trend data.
• Composition identified.
• Retention approved.
• Options evaluated.
• Decision documented.