Skip to main content

How can we help you?

Druva Documentation

How user migration in a storage pool works

You can add multiple storages to a storage pool. Storages within this pool respond to backup and restore. However, when a storage in a pool is filled to 80% of its capacity while other storages are relatively free (occupied by up to 70% only), the storage pool becomes "unbalanced". New data requests are not assigned to the storage having less than 30% free space; instead, users assigned to it are automatically migrated to the freer storages. User migration ensures fair distribution of load between member storage. 

Note: User migration is an automatic process. 
This diagram explains how user migration works within a pool. 
Data Migration Flow - Support Process.png
 
Step 1: The Master server assigns a backup or a restore request to a storage. 
Step 2If storage in a pool is filled to 80% of its capacity while other storages are relatively free (occupied by up to 70% only), the storage pool becomes "unbalanced". Backup and restores requests to this storage stop, and it is marked for migration. 
Step 3
  1. The Master server initiates a scan on the storage to identify users that can be migrated to other storages within the pool. If the scan identifies consistent users, these users are moved to along with their snapshots a free storage, thus freeing up space on the source storage. The storage pool returns to a balanced state.
  2. If the Master server cannot identify consistent users, it generates a Low Free Space Available alert. 
Note: Backups continue to progress during this time. However, compaction and synchronization are temporarily halted. 
Step 4
  1. The Master server initiates a scan on the destination storage to determine if the newly migrated users are consistent. If users are consistent, the Master server changes the ConfigDb entry to reflect changed storage. This completes the migration. At this stage, the source storage is compacted. 
  2. If users are inconsistent, a compaction runs on the destination storage to remove invalid entries. 
Note:
  • User migration fails if consistency checks described in step 3 and step 4 do not succeed.
  • At the end of successful migration, user data is backed up to the new storage.
  • A status of migration activities is saved to inSyncMigration.log. This file is created on storage nodes.