TürkçeDemo
Menu

Procedure

Move repository objects safely to another storage component

Stream objects between Local or S3 storage, verify checksums, and update repository assignment through a durable task.

Content statusVerified in sourceDocumentation versionLatest
Smart Kubaba Storage screen with Local storage health, usage, and transfer actions
The Storage view shows component state, health, and usage before source or target selection, while Transfer starts the supported migration flow.

Role and prerequisites

Storage-component management and starting a transfer require AdministerSystem.

  • Source and target must differ; the target must be ACTIVE and the source must not be DISABLED or MIGRATING.
  • Health tests must pass for both storage components, and target capacity, access, and credential chain must be verified.
  • Define a maintenance window and rollback owner for the write interruption on repositories assigned to the source storage.

Procedure steps

  1. On Administration > Storage, run Health Test and Usage Refresh for source and target, then capture Assigned Repositories as the control inventory.
  2. Choose Transfer, verify source and target components, and start the operation. Confirm both storage components and source repositories become MIGRATING at startup.
  3. In Tasks > Cleanup & Storage, monitor repositoryCount, candidateCount, processedCount, transferredBytes, and errorSummary.
  4. Confirm the worker streams each object to the same repository-owned key on the target and updates the storage reference only after size and SHA-256 verification.
  5. When the run is Completed, confirm repositories are assigned to the target and ACTIVE, then review source-object deletion counters.
  6. Perform sample package reads through selected Hosted, Proxy-cache, and Group paths; reconcile checksums with Package Usage and operation or audit evidence.

Success criteria

  • The run is COMPLETED; processedCount matches candidateCount and transferred bytes or objects reconcile with target inventory.
  • All repository storage assignments point to the target, with no remaining active object in the source storage-reference query.
  • Sample downloads return the same SHA-256 and size, and the STORAGE_TRANSFER operation log shows a completed job.

Failure and security boundaries

  • Normal writes are blocked during transfer; changing storage in repository edit affects only new writes and does not replace this procedure.
  • A checksum or size mismatch prevents reference update. If the run fails, storage and repository states are restored from startup snapshots.
  • Only one global transfer may be active; a PostgreSQL partial index and lease prevent races across replicas.
  • Do not remove the old filesystem, bucket, or credentials before successful completion and package reads are verified.