On-prem object storage: Dell ECS vs IBM Cloud Object Storage in practice

Why compare and test before buying

On paper Dell ECS and IBM Cloud Object Storage often look the same: both promise S3 compatibility and familiar features for archive and backups. But in practice “S3” is not a single standard but a set of APIs and behavioral nuances. Differences usually don't show up in simple PUT/GET, but in details: how headers are handled, which errors are returned, how access policies work and what limits exist in a specific version.

When you deploy object storage on‑prem, the cost of mistakes is higher. After deployment you may discover risks that are hard to roll back: backups suddenly become “unsupported,” an archive fails audit because of retention, an application writes data but cannot read versions correctly, or migrating to another storage takes months.

You should test both manually and with your vendor. Manually, test what affects your applications and processes: compatibility with your SDK/client, common operations, recovery from errors, versioning behavior and basic performance at your object sizes. It makes sense to trust the vendor for what’s hard to prove without a lab: WORM guarantees, legally meaningful retention settings, certifications, and confirmation of compatibility with particular backup systems and their modes.

Before a pilot, gather requirements; otherwise comparisons become a matter of “taste.” It's handy to collect inputs on a single sheet: from InfoSec (immutability, encryption, audit, role separation), legal and compliance (retention periods, retention extension, eDiscovery), data owners (RPO/RTO, access frequency, recovery window), infrastructure (network, failure domains, growth plans, object and bucket limits), and applications (which S3 features are actually used: versioning, multipart, tags, ACL/policy).

With these inputs, a pilot becomes a clear check “for our needs” rather than a brand argument.

Key terms without extra theory

To compare on‑prem solutions fairly, align on terminology first. Otherwise it's easy to confuse marketing names with real S3 API capabilities and hit surprises during the pilot.

S3 API in simple terms

The S3 API is a set of commands applications use to work with objects. Most tests reduce to whether a system responds the same way to typical requests.

A bucket is a container for data, like a top‑level folder. An object is a file plus metadata. A key is the object name inside a bucket; it often looks like a path but is technically just a string. Metadata are additional fields about an object (for example, type, tags, custom attributes). ETag and integrity checks are values clients use to ensure what uploaded matches what was intended.

If two systems handle keys, metadata or integrity checks differently, an application may behave unpredictably even if basic uploads and downloads succeed.

Versioning and WORM

Versioning means that deletion or overwrite doesn't destroy the previous variant but creates a new version. For users this is good (you can roll back), but for administrators it increases consumption. Old versions take space and lifecycle policies become necessary. It's important to understand in advance how quotas and reporting account for versions and how quickly obsolete versions are removed by rules.

WORM (Write Once Read Many) is an immutability mode: an object cannot be modified or deleted until retention expires. Retention is a timer that tells the system to keep data until a specific date. Legal hold is a separate stop‑gap for deletion, usually without an end date, used during investigations or disputes.

Practical example: a 7‑year financial archive. Retention sets the period, while legal hold can freeze selected documents even after 7 years. When comparing systems, test both modes separately, not just a “WORM” checkbox in the spec.

Comparison criteria: what matters for on‑prem

For on‑prem object storage, matching real workload matters more than a feature table. Start with the application: which S3 operations does it perform daily. Often it's enough to have PUT/GET/LIST/DELETE, but there can be nuances: multipart upload, presigned URLs, tags, ACLs/policies, HEAD requests, range reads.

Application compatibility and integrations

Make a short list of critical scenarios and test them in the pilot. For example, a backup system may require versioning and locks, while analytics needs fast LIST by prefix and parallel reads. If you have multiple systems, choose the most demanding case as the benchmark.

At the same time evaluate security. On‑prem, you are responsible for accounts, key rotation, rights separation and audit. Check how easy it is to create access policies, enable encryption and produce audit logs acceptable to your InfoSec team.

Before tests, agree on basics: which S3 operations are needed (including multipart, versions, tags, ranges), how authentication and key management are handled, mandatory InfoSec controls (encryption, audit, roles), how you update and roll back the system, and how you preserve and restore configuration.

Operations and TCO

Data lifecycle on‑prem often matters more than peak throughput. If lifecycle rules move or delete data, verify their impact on applications and reports.

Calculate the cost of versions and WORM separately. Versioning may appear negligible in a test but explode in production: “reuploading a file” becomes a new object. WORM and retention amplify the effect: you can’t delete data until retention ends, so plan capacity ahead. Example: a governmental document archive with 5‑year retention needs space not only for files but also for versions, metadata and system logs.

Steps to validate basic S3 compatibility

Basic S3 compatibility for on‑prem object storage is best verified with a small set of repeatable tests rather than quoting datasheet phrases. Record which clients and SDKs your applications use: behavior can differ even with similar requests.

Start with a minimal set of operations and run them identically against Dell ECS and IBM Cloud Object Storage. It's convenient to document this as a short test plan with the same inputs and expected results.

Minimal test set

Usually 4–6 scenarios that mimic real app behavior are enough:

• PUT, GET, LIST, DELETE for a single object and for sets by prefix.
• Upload and read large objects (for example, 5–20 GB) and boundary sizes relevant to your software.
• Keys with spaces, Cyrillic, symbols like +, %, parentheses, and very long names.
• Deep prefixes (logical “folders”) to test length limits and LIST behavior across levels.
• Retries under network failures: repeat the same PUT/DELETE 3–5 times to observe idempotency and consistent results.

After each scenario compare responses: HTTP codes, error messages and reproducibility. If an application expects 404 when reading a missing key but another solution returns a different code or error format, exception handling often breaks.

What to log in the protocol

Record SDK, utility versions and parameters (region, signing method, address style, timeouts). In integration projects this often saves days: when something “doesn't add up,” it's easier to see if it's an S3 implementation detail, a config or a client incompatibility.

Small example: one service writes filenames in Russian and lists by prefix to build an index. If encoding or escaping is handled differently, you'll see it on the first run instead of after migrating data.

S3 features that most often break compatibility

Even when both solutions claim S3 compatibility, pilots reveal details. For on‑prem object storage this is especially noticeable: applications use not only basic PUT/GET but also edge features where Dell ECS and IBM Cloud Object Storage may differ in limits, error responses and default behavior.

Multipart upload: interruption and resume

Multipart often fails not because uploads themselves fail but because of pauses and retries. Verify that a client can interrupt an upload, resume it after an hour, and clean up “dangling” parts properly. Check timeouts, minimum part size and reactions to network loss: one platform may return a clear error and keep context, while another forces a restart.

Permissions, encryption, metadata and concurrency

Typical divergence points are:

• Access policies: prefix denies, explicit Deny, inheritance of rights on objects.
• Encryption: support for SSE‑S3 and SSE‑KMS, required headers, behavior when reading without a key.
• Metadata and tags: limits on size and number, case sensitivity, preservation during copy.
• Parallel operations: conflicts when multiple uploads target the same key, reads during overwrite.
• Errors and response codes: do HTTP codes and error messages match your SDK’s expectations?

Imagine a medical imaging archive: a service writes files in parts, sets tags (study type, retention), and access to a prefix is restricted by department role. Under 50 parallel uploads you need clear logs and audit entries showing who was denied and why, and retries must not create duplicates.

If you run a pilot with an integrator, ask them to run scenarios using the same client and SDK your application uses, not just a “test utility.” That quickly reveals incompatibilities you would otherwise see only in production.

Versioning: tests, expectations and cost

Versioning on on‑prem object storage changes assumptions: a key is no longer “one file.” In the S3 API each record gets a versionId; deletion often becomes a delete‑marker rather than freeing space.

Start simply: how is versioning enabled and where is it visible? Ideally you enable it once on the bucket, and subsequent PUT/GET/DELETE return expected headers and version identifiers, and the management console shows history.

Minimal tests

Run the same sequence on Dell ECS and IBM Cloud Object Storage:

• Enable versioning on a test bucket and upload an object 3 times under the same key.
• Delete the object with a normal DELETE and verify the object is no longer visible but versions remain.
• Restore by requesting a specific versionId or removing the delete‑marker (if created).
• Run two parallel overwrites of the same key and observe how many versions appear and which becomes current.

A capacity surprise: storage grows fast. Each overwrite stores a full new object; delete‑markers and incomplete multipart parts can accumulate. So compare not only the feature but lifecycle policies: when old versions are deleted, how many are kept, and who approves that (security, data owner, compliance). For contract archives it's common to keep versions 30–90 days then clean them to avoid doubling storage in months.

WORM and retention: how to test immutability

If on‑prem object storage is used for archives, financial docs or medical images, validate WORM by behavior, not by the vendor’s claim.

WORM usually appears in two forms. One is strict immutability at the object level: written once and then only read. The other is retention‑based: an object can only be deleted or replaced after retention expires. Regulators often prefer the latter because it’s easier to prove data was held for the required period.

Test retention as a policy, not a checkbox. Verify supported minimum retention periods, whether retention can be extended without rewriting the object, and what happens when someone attempts deletion before expiry. Also see who can change these settings. If an admin can remove protection retroactively, WORM is just a formality.

Legal hold is needed when scheduled retention is interrupted by an investigation or dispute. Simple test: set a hold, wait for retention to expire (or use a short test retention), and confirm the object still cannot be deleted.

Minimal test set for Dell ECS and IBM Cloud Object Storage:

• Upload an object, enable WORM and set a short retention.
• Attempt to overwrite the same key: expect denial or creation of a new version while preserving the protected copy.
• Try to delete the object before expiry: expect denial.
• Extend retention and confirm the new date is applied.
• Enable legal hold and ensure deletion is blocked regardless of retention.

Don’t forget audit. Tests require events: setting and changing retention, placing and removing legal hold, delete and overwrite attempts, and who performed actions and from which account. Without these traces immutability is hard to prove even if settings are correct.

Observability, audit and operations

Even if APIs and features matched in the pilot, operations often reveal other pain points: can you see who did what, can you quickly understand why operations slowed, and how early do you learn about problems. For on‑prem object storage this matters because monitoring and incident analysis are your responsibility.

What should appear in logs and reports

Start with two streams: access logs (client operations) and admin logs (config and policy changes, user actions). Ensure entries include time, user or access key, bucket, prefix/object, IP, response code and latency. Also log policy changes, enabling versioning, retention/WORM settings, and creation/deletion of accounts and keys.

Next, storage reports. A practical minimum: total volume, growth over a period, distribution by bucket, number of versions, share of “old” versions and “hot” prefixes (where most requests and errors occur). Without this it's hard to explain sudden capacity growth: new data, versions or application garbage.

Alerts and SIEM integration

Test alerts during the pilot: artificially fill a pool to threshold, take a node offline, cause replication errors (if used) and confirm notifications are timely and clear.

In SIEM send events that help investigations: failed authentications and a spike in 401/403, mass deletions (especially by prefix) and version deletion operations, changes to bucket/ACL/versioning/retention policies, replication errors and node degradation, capacity thresholds, and unusual latency or 5xx spikes by bucket/prefix.

Minimal operating routine

To prevent data becoming “dead weight,” define a simple schedule.

Daily — check alerts for capacity, degradation, replication and 5xx. Weekly — report on growth, top buckets/prefixes, and version share. Monthly — audit admin actions, access keys and policy changes. On incident — preserve log samples and a timeline of actions.

Example: in a WORM archive someone changes access policy and an application starts getting 403 and spamming retries. If logs show who changed the policy and which requests failed, you fix the issue in hours instead of days.

Common mistakes when comparing Dell ECS and IBM COS

The most common problem is turning the comparison into “who uploads faster via CLI.” For real selection of on‑prem object storage you must test the way production will use it: same libraries, same application, same access patterns.

Many stop at AWS CLI and are happy that “S3 compatibility exists.” Later they discover the SDK or application issues different requests: specific headers, different signing, different timeout and retry behavior. In a pilot run at least one SDK (for example, Java or .NET) and a real scenario of your software, not just manual commands.

Another trap is testing only small files. When backups, media or logs of tens of gigabytes appear, multipart upload, parallel parts, interruptions and resume come into play. That’s where small incompatibilities and differing limits on minimum part size, maximum part count and abort behavior show up.

Versions and WORM silently consume capacity

Versioning and WORM are useful but they quickly increase actual usage. Typical surprise: “the bucket shows 200 TB of data but space is running out.” Cause: old versions, unfinished multipart parts, and retention that cannot be shortened.

Before the pilot agree simple rules: which buckets are versioned and which are not; where WORM is required and where ordinary archive suffices; how old versions and multipart garbage are cleaned; retention periods and who approves them.

Comparing without a protocol becomes an argument

If you don't record settings and results, after two weeks no one remembers where versioning was enabled, what retention was set or what parameters were used. Create a “pilot passport”: software versions, bucket configs, policies, scripts, metrics and brief conclusions for each test. Then the Dell ECS vs IBM Cloud Object Storage comparison is objective.

Short checklist for the pilot

Build the pilot as a set of short repeatable checks, run the same commands and clients against Dell ECS and IBM Cloud Object Storage. This quickly shows where S3 compatibility ends and where configuration is the issue.

Compact checks that usually yield maximum signals in 1–2 days:

• Basic ops and clients. Create bucket, upload/download object, list objects, HEAD/metadata, delete, ACL/policies (if used), generate pre‑signed URLs (if needed). Run tests with at least two clients: AWS CLI and your main app or backup software.
• Multipart and parallel uploads. Upload several large files (e.g., 50–200 GB) with multipart, then repeat with parallel threads. Record throughput, error rate, behavior on network loss and resume.
• Versioning: restore and cleanup. Enable versioning, overwrite the same object 5–10 times, delete the current version and restore a previous one. Test cleanup: delete‑marker, deleting specific versions, lifecycle rules (if applied).
• WORM: retention, legal hold and delete attempts. Enable Object Lock (or equivalent), set short retention, place legal hold, then try to delete or modify the object. Verify API responses and visibility in console and logs.
• Logs and audit. Ensure you can see who performed actions, when, from which key/account, and that events are not lost under load.

Also evaluate capacity and growth: versions quickly inflate actual consumption, and WORM/retention block garbage cleanup. In the pilot model one month: average daily growth, fraction of overwrites, retention period, expected number of versions and spare capacity for replication/EC and metadata overhead.

Example scenario: archive with WORM and recovery requirements

Imagine an organization storing contracts, invoices, inspection results and scanned documents. Regulations forbid modification or deletion for 5 years and audits must quickly prove data was untouched. They choose on‑prem object storage and enable WORM (retention) at bucket or prefix level.

Data flows into two streams. “Active matters” are read daily by legal, finance and procurement. “Archive” is rarely opened but must survive failures and audits.

Define roles before the pilot so tests are fair: the uploader operator can write new objects but cannot delete or change retention; an auditor has read‑only access and log access; the administrator manages accounts and policies but should not be able to bypass WORM; the application uses a separate access key with minimal rights.

Test incident: an operator accidentally deletes a “folder” of current scans. Expectation: deletion does not destroy data but creates a delete‑marker or new version. Then an admin or operator (per policy) restores the previous version and records recovery time.

Final WORM check: with the same accounts try to shorten retention, overwrite the file with the same key, delete old versions and erase the object “by bypassing” protections. Result should be the same: until 5 years pass no one — operator or admin — can make the object mutable or vanish, and audit logs show all attempts.

Next steps: organizing the pilot and rollout

Start with specifics: what data will go into on‑prem object storage and why. Not just “how many TB,” but retention periods, immutability requirements, who can access and which applications will actually read and write via S3.

Put requirements on a single sheet and align them with security and data owners. This is where details surface: do you need a deletion ban, how long to keep versions, who approves retention, and which audit logs are mandatory.

Pilot plan

The pilot should validate your working scenarios. Define success metrics in advance so there’s no debate about impressions later.

A basic plan usually looks like: choose a test dataset (typical files, sizes, operation frequency, peaks), describe scenarios (upload, read, delete, versioning, WORM, recovery), set metrics (latency, throughput, error count, recovery time), define roles and access (who is admin, who reads, who can change policies), and agree on report format and decision criteria.

Prepare infrastructure and operations

Before buying hardware assess network and fault tolerance. For object storage the bottleneck is often network and correct redundancy: links, switches, power, rack space, quorum scheme and failure zones.

Decide who will operate the system post‑launch. You need maintenance windows, monitoring, incident response and regular checks of retention and audit.

If you hire an integrator, treat the pilot as a project with a single test plan, fixed settings and a results protocol. For example, GSE.kz can cover practical deployment (servers, integration, 24/7 support and service network) and help make the pilot reproducible with your clients and SDKs.