Setting Up Selectel Cloud Storage (S3-Compatible Storage)

Selectel Cloud Storage: where object storage breaks

Object storage looks like a simple service: upload a file, get a link. As long as a bucket has tens of thousands of objects, that is true.

Once the count reaches millions and several teams write to it, Selectel Cloud Storage shows the same bottlenecks as any S3-compatible platform.

The first failure is volume growth. Versioning and incomplete multipart uploads accumulate invisible copies: listing objects in a bucket slows down, and data that no one has opened for months continues to take up space and be billed.

The second is access policies that drift apart. While rights and keys are issued manually through the panel, publicly readable objects, duplicate keys, and accesses left over from departed contractors appear in the bucket. Revoking such access requires a full enumeration.

The third is degradation of exports under peak load. Many small objects, parallel exports, and frequent listings turn a routine task into a chain of retries and timeouts; not only writes suffer, but reads too.

The fourth is manual operations instead of a procedure: archiving, key rotation, and data migration rely on a specific engineer's memory.

Next, we break down how this is closed by configuration: lifecycle policies, access roles, and a reproducible procedure instead of manual actions.

What changes in the infrastructure after data migration

The failure class caused by overflow goes away

Local volumes no longer hit the ceiling: working data is moved to fault-tolerant storage, and only what is needed here and now remains on the servers. Partition overflow stops being a cause of incidents, because volume growth is no longer tied to the size of a specific disk. Nightly exports complete — previously backups were lost right in the middle.

Data recovery time drops from hours to minutes

Recovery comes from object storage by the required prefix, not from tape and not by manually assembling scattered archives. The recovery procedure becomes predictable: the engineer knows in advance which set of objects to restore and in what order. For critical services, this is the difference between a planned window and full downtime.

Object lifecycle is delegated to policies

Retention rules themselves move rarely used data to a cold class and delete anything older than the agreed period. The backup registry stops growing indefinitely, while rollback to a previous state is still possible. Storage costs stop growing along with volume.

Routine data operations run on a schedule

Upload, integrity checks, rotation, and backup to the cloud move into scheduled tasks and scripts. The share of operations that run without an engineer's involvement reaches most regular scenarios.

The human remains where a decision is needed: handling non-standard situations and verifying recovery.

To understand which of the effects will provide the greatest benefit in your infrastructure, you need to look at current volumes and procedures — that is where we start the analysis.

Storage classes and access modes: comparison of options

Storage classes in Selectel Cloud Storage differ not only in the speed of access to an object, but also in the minimum retention period and the consequences of early deletion.

The hot class serves data immediately and is suitable for what is read constantly; cold and archive are cheaper to maintain, but an object must be restored before it is served.

The class is assigned by a lifecycle policy: after a specified number of days from the last write, the object automatically moves to the cold layer, and after the retention period expires, it is deleted.

The storage class and access mode are set independently: an object can reside in the archive layer and still be served via a signed link. Below are the combinations from which we assemble a configuration for the load profile.

Next, we lock down lifecycle rules and access separation in the configuration so that storage classes and access modes do not have to be edited manually.

Implementation order: from audit to handover

Storage implementation is not creating a bucket and issuing a key, but a sequence where each step relies on the result of the previous one. A skipped audit results in reworking policies after migration, and untested recovery results in downtime at the moment of failure. The order in which we run such projects, including Selectel Cloud Storage, is below.

1. Infrastructure audit. What is stored where now, daily growth, who writes and reads, peak loads, current backups and their retention periods.
2. Schema design. Layout across buckets and prefixes, access classes for hot and archive sets, naming rule, permissions model.
3. Configuration of storage and policies. Versioning, lifecycle rules, encryption, source request restrictions, object access logging.
4. Data migration. Migration in waves with delta syncing; reconciliation by object count and checksums reveals discrepancies before cutover.
5. Recovery testing. The copy is deployed in a separate environment: we measure time to operational state and integrity, not the mere presence of files.
6. Documentation. Diagrams, key rotation procedure, access separation, on-call instructions — the work does not depend on one person.
7. Handover to operations. Access for the team, walkthrough of typical operations and incident scenarios, support during startup.

Implementation does not end there: we set up monitoring of volume and access errors, alerts for anomalies, and a recovery testing procedure. That is why storage configuration becomes a manageable process with a predictable handover to operations.

What remains in the infrastructure after the work

After the work, the customer's team retains not only connected storage, but also a full set of artifacts they can use to develop and maintain it without us.

We verify each item in a live environment: the customer's engineer performs the operation themselves, while we explain what is happening and why it is configured that way.

• Placement scheme: which containers are created, for which tasks, how environments are separated, where data flows between services and storage.
• Storage configurations: Selectel Cloud Storage parameters, enabled versioning, lifecycle rules, distribution across storage classes, and encryption settings.
• Access policies and roles: service accounts, least privilege principle, separation by containers and prefixes, procedure for granting and revoking access.
• Backup procedure: what is backed up, at what frequency, what retention depth, and how regularly recovery is tested.
• Rotation and retention rules: how long object versions live, what goes to archive, what is deleted, who is responsible for reviewing retention periods.
• Storage documentation: architecture description, application integration points, known limitations, and failure behavior.
• Team instructions: typical operations — connecting a new service, granting access, restoring an object, diagnosing write and read errors.
• Monitoring and alerts: set of metrics, trigger thresholds, responsible parties, and actions for degradation.

We separately record knowledge transfers: the set of artifacts is stored in a repository alongside infrastructure descriptions, changes go through review rather than manual edits in the panel.

This way the configuration does not diverge from reality, and a new engineer gets up to speed from documentation, not from colleagues' stories.

Implementation case study: how recovery time was reduced

How it was before migration

Backups and exports were collected on local disks of three servers; no one limited retention. Recovery after a disk failure took 4–6 hours, and during all that time some files and reports were unavailable. Each export required manual reconciliation: archive size, object composition, access granting.

The share of successful exports stayed around 80% — the rest failed due to timeouts and corrupted objects. The archive registry grew without limits, and no one could say exactly what could be deleted and what needed to be kept for rollback.

What was changed

Objects were migrated to Selectel Cloud Storage in stages, in batches, with checksum verification on each batch. Versioning was enabled — rollback to a previous state no longer depended on whether someone had managed to overwrite the object.

A lifecycle rule keeps the latest versions for each key and cleans up the rest, and rights are granted to roles rather than specific people.

Export became automatic: object composition and integrity are checked by the system, and the engineer gets involved only on a monitoring signal.

What was achieved

“A disk failure used to mean a night shift and manually sorting through archives,” says our engineer who led the migration. “Now recovery fits into half an hour.” The customer adds: “We learn about a failure from monitoring, not from users.”

How S3 storage in Selectel differs from a block disk

These are two different access models, not a fast and slow version of the same thing.

A block disk is attached to a server as a volume, a file system is created on top of it, and the application works with it as with local storage — with locks, positional reads, and a transaction journal. Databases, queues, and everything sensitive to response latency live on exactly such a volume.

Object storage is structured differently: a flat key space inside a bucket, access via an S3-compatible software interface. An individual operation responds more slowly, but scale and parallelism are different — dozens of clients simultaneously read the same object.

Versioning, lifecycle rules, and cross-zone copying are configured on the storage side, not in the application.

The choice is dictated by the task, not the data volume. Files, media, archives, backups, exports for analytics — object storage. Data that is rewritten row by row and requires locks — a block volume.

The working scheme is more often hybrid: the database runs on a block volume, while its dumps and journal files go to Selectel object storage. Recovery from a backup then does not depend on the volume size or on where the server is physically located.

Another important point is that the S3-compatible interface is portable: backup and export tools work with it without rewriting.

But mounting a bucket as a regular disk for transactional data is not advisable — the semantics of operations are different, and integrity will have to be ensured manually.

Technical doubts before implementing storage

Before including Selectel Cloud Storage in a production environment, engineers ask the same five questions: will code need to be changed, how will export behave under load, what will happen to access. Below are short technical answers.

What will happen to latency during export?

The response to an object operation is fractions of a second when accessed from the same region; the bottleneck is more often the channel, not the storage. We upload large files in parts in parallel — a connection drop does not fail the export; only the missing parts are resumed.

Can data be migrated without downtime?

Yes: first we copy the array in the background, then switch reads, while writes briefly go to both environments, and we reconcile discrepancies from the change log.

Downtime is seconds to switch the pointer; returning to the original point is possible until integrity is confirmed.

How are service and human accesses isolated?

Each application gets a separate account with rights only to its own prefix; policies are described declaratively and stored in version control. Employees receive temporary keys for a session, so access is revoked automatically, and requests are visible in the log.

What happens during a storage incident?

Data is stored with redundancy, so a media failure does not lead to object loss. We configure alerts by latency and error rate thresholds in advance, and we document the escalation procedure on the provider side in the procedure.

Let's discuss the task: we will select a storage mode and estimate the work

To make the estimate substantive rather than a rough guess, a short description of the task is enough — there is no need to prepare a technical specification in advance.

The payload profile is more important than formalities: Selectel Cloud Storage is an S3-compatible storage, and the storage mode and scope of work depend on where delivery is, where backups are, and where the archive is.

What is enough to send to get started:

• data volume and nature: how much it occupies now, how much is added per month, average object size;
• access scenarios: public delivery of static content, media delivery, backups, exchange between services;
• access requirements: private and public containers, role separation, separate keys per environment;
• lifecycle rules: how many versions to keep, when to move to the cold class, what to delete permanently;
• what already works: current storage, integrations, a migration scheme without downtime;
• constraints: maintenance window, deployment region, fault-tolerance requirements.

In response, we will return an estimate of storage work and an implementation plan: selection of a storage mode for your load profile, container scheme, access policies, and data migration order.

We confirm receipt within one business day and ask clarifying questions; we provide the analysis with the estimate within a couple of business days after your answers.

Next, we agree on timelines and move to the first validation: a test container, verification of behavior in real scenarios, rollback if there is a deviation.

We discuss the task directly with the engineers who will do it — describe what you store and how you use it, and we will come back with a plan.