Migrating from Airgap to AirGap for ObjectScale

What this is about

You have been running Airgap (the previous copy product) against an ObjectScale source bucket. Your customer's vault target already contains some or all of that data.

AirGap for ObjectScale replaces Airgap. The goal of this migration is to avoid re-copying anything Airgap already copied.

Airgap writes objects to the target bucket. Some ecs-sync-based deployments leave a provenance marker (x-amz-meta-x-emc-source-etag), which the console can use as a Tier 2 match.

In many older or partial deployments the marker is absent. The copy job must then work out which target objects are faithful copies of the source. It uses size, ETag, and optionally date or range-sample matches. This is the job of Target Skip Mode.

This page describes the three scenarios you will see in the field and how to configure each one in the console. It also explains how to hand off to incremental sync afterward.

How the console skips already-copied data

When you start a full-sync copy job in Target Skip Mode, every source object is checked against the target bucket in tier order. As soon as one tier matches, the object is skipped and no copy traffic is used. If no tier matches, the object is copied with the full source-to-target byte transfer (Tier 3).

Tier	What it compares	Cost	When it helps
Tier 1	Source ETag and size equal target ETag and size.	Free (LIST data)	Single-part objects identical on both sides.
Tier 1.5	Sizes match and the source object's Last-Modified is before your cutoff date.	Free (LIST data)	Source objects last modified before the cutoff whose size matches the target.
Tier 2	The target has x-amz-meta-source-etag or the legacy x-amz-meta-x-emc-source-etag, and it equals the source ETag.	1 HEAD request	Objects the console copied in a previous pass. Also objects copied by legacy ecs-sync or Airgap deployments that left their own provenance marker.
Tier 2.5	Sizes match and 3 byte ranges (begin, middle, end) match.	3 ranged GETs on each side (source and target)	Last-resort skip for large objects when no cutoff date is available. Use only when the source bucket is read-only during migration.
Tier 3	No match, so a full copy.	Bytes transfer	Anything that fell through every skip tier.

The x-amz-meta-source-etag marker is written by every Tier 3 copy this console makes. The legacy marker is written by ecs-sync.

The Tier 1.5 cutoff date

Y is the date Airgap was installed and first started copying. Enter the day before Y (UTC) as the cutoff date.

You enter this date in the dispatch dialog when you launch the job. The copy job trusts every target object whose source object was last modified before the cutoff and whose size matches the target.

warning

Use Tier 1.5 only when nothing was written to the target bucket before the cutoff.

Tier 1.5 trusts size and date alone and never reads the object. A wrong Y means objects are skipped that were never copied correctly. Enter only a Y the customer has confirmed.

The cutoff is a UTC date. The backend turns it into the end of that UTC day. An object copied on the install day and changed later that day at the same size is skipped, which is why you enter the day before Y.

Selecting the checkbox pre-fills today's date. Today's date trusts every same-size object on the target, so always replace it with the day before Y before you start the job.

Which scenario applies

Scenario	Airgap status when AirGap for ObjectScale is installed	Can the customer tell you when Airgap was installed?
A: Partial copy	Started, ran for a while, and was stopped before finishing.	Yes
B: Completed copy	Started and completed a full copy. The source has had live writes since.	Yes
C: Unknown history	Was used at some point in the past.	No

Scenario A: Airgap started copying, then stopped

Example timeline

Date	What happened
2025-12-01	The customer installed Airgap and started the first copy job. This is Y.
2025-12-15	The customer canceled Airgap. About 60% of the bucket had been copied.
2026-05-26	The customer installed AirGap for ObjectScale.

Launch the first migration pass

1. Make sure the source bucket's protection group is still in Preparation Mode. A full sync cannot be started for a group in Vault Mode.
2. Open Cyber Vault > Full Data Sync Management > Vault Jobs.
3. Select the policy for the customer's source bucket and click Start Full Sync. See the Vault Jobs help page for the policy fields.
4. In the dispatch dialog, under Copy mode, choose Target Skip (the third option).
5. Set the tier checkboxes:
   • Tier 1 (strict ETag match): always on.
   • Tier 1.5: ON. Enter cutoff date 2025-11-30, the day before the customer installed Airgap on 2025-12-01.
   • Tier 2 (provenance): ON.
   • Tier 2.5 (range probe): OFF.
6. Click Start 1 Sync.

The job walks the source bucket and does the following:

• Skips objects Airgap already copied that existed before 2025-12-01. This is most of the bucket.
• Copies anything modified or created after 2025-12-01, which are the writes since Airgap was installed.
• Copies anything Airgap missed, which is the 40% it never reached.

Why a second pass is needed

The source bucket is live, and users write to it the whole time the copy job walks it. Any new object that lands in a part of the bucket the job has already passed is missed by Pass 1.

Run Pass 2 right after Pass 1 finishes, with the same settings. Pass 2 does the following:

• Re-skips everything Pass 1 skipped. This is cheap.
• Picks up and copies the writes that Pass 1 missed.
• Skips the objects Pass 1 already copied, through Tier 2. Every Tier 3 copy is stamped with the source-etag marker, so Pass 2 recognizes them without re-copying.

Pass 2 is much faster than Pass 1 and reports far fewer copies. Run a Pass 3 if the copied count is still high. Stop running new passes when the copied count drops near zero.

Scenario B: Airgap completed the full copy, then live writes continued

Example timeline

Date	What happened
2025-11-01	The customer installed Airgap. This is Y.
2025-11-30	Airgap finished the full copy of the bucket.
2025-11-30 to 2026-05-26	The source bucket received continuous live writes (new objects and modifications) for 6 months.
2026-05-26	The customer installed AirGap for ObjectScale.

Launch the first migration pass

Use the same steps as Scenario A. The cutoff date is still the day before Y: 2025-10-31 (Y is 2025-11-01, the date Airgap was installed). It is not 2025-11-30, the date Airgap finished.

Use the install date and not the completion date because anything Airgap modified during the copy could have been captured in an in-flight state. The safest trust line is the date before Airgap touched anything.

Configure the tiers as follows:

• Tier 1: always on.
• Tier 1.5: ON, cutoff 2025-10-31.
• Tier 2: ON.
• Tier 2.5: OFF.

During Pass 1:

• Objects from before Y, which is most of the bucket, are skipped through Tier 1 (single-part) or Tier 1.5 (multipart).
• The 6 months of writes after Y are copied through Tier 3.

Use the same multi-pass approach as Scenario A. Run Pass 2, and Pass 3 if needed, until the copied count converges.

Scenario C: The customer cannot tell you when Airgap was installed

When this happens

• Operational records are lost.
• Several vendors or copy products were used in sequence.
• The platform changed hands.
• Airgap was tested ad hoc with no documented install date.

Configuration

Without a trusted Y, Tier 1.5 is not safe. You cannot enter a cutoff date you do not know.

Tier 2.5 (range probe) samples 3 byte ranges from each object and skips on a match, without needing a date or marker. It is probabilistic, and the dispatch dialog says to use it only when the source bucket is read-only during migration.

This gives two variants:

Variant	Tier settings	Passes
Source bucket is read-only during the copy (writes stopped for the migration)	Tier 1 ON, Tier 1.5 OFF, Tier 2 ON, Tier 2.5 ON	One pass is enough. Allow writes again when it finishes.
Source bucket stays live (writes continue)	Tier 1 ON, Tier 1.5 OFF, Tier 2 ON, Tier 2.5 OFF	Objects that cannot be matched are copied again. Run 2–3 passes until the copied count stops changing.

Start the job as in Scenario A: Cyber Vault > Full Data Sync Management > Vault Jobs > Start Full Sync. Set Copy mode to Target Skip, with the tier settings for your variant.

What to tell the customer

Pass 1 in Scenario C is significantly slower than Pass 1 in Scenario A or B.

With Tier 2.5 ON, every object that reaches it costs 3 ranged GETs on both source and target. An object reaches Tier 2.5 when:

• Its sizes match.
• It has no Tier 1 or Tier 2 match.
• It is at least the Tier 2.5 minimum file size set in Setup & Settings > Advanced Settings.

At the default 1 MB sample size, that is 3 MB read per side per object. For 10 million such objects, that is about 30 TB per side. With Tier 2.5 OFF, those objects are copied in full instead.

Pass 2 and later passes are much faster, because Tier 2 absorbs every object the console has already copied.

tip

If the customer can give you any defensible install date, push them to Scenario A or B with the most conservative bound. A coarse "we installed Airgap sometime in Q4 2024" works, with a cutoff of 2024-10-01.

Tier 1.5 with any conservative cutoff is free. It catches a large fraction of what Tier 2.5 would otherwise have to range-probe.

Configuration summary

Setting	Scenario A	Scenario B	Scenario C
Tier 1	Always on	Always on	Always on
Tier 1.5 cutoff	Day before the Airgap install date (Y)	Day before the Airgap install date (Y)	OFF
Tier 2	ON	ON	ON
Tier 2.5	OFF	OFF	ON only if the source bucket is read-only during migration. Otherwise OFF.
Number of passes	2–3, until the copied count converges	2–3, until the copied count converges	1 if the source bucket is read-only during migration. Otherwise 2–3, until the copied count converges.
Pass 1 speed	Fast	Fast	Slow (range-probe bandwidth)
Pass 2 speed	Very fast	Very fast	Fast (Tier 2 absorbs Pass 1 copies)

After the migration passes: hand off to incremental sync

A Target Skip pass is walk-based. Every pass lists the entire source bucket and compares it object by object with the target.

Ongoing protection does not walk. Incremental sync copies only what changed. The console ingests the source cluster's audit events and groups them per copy policy into 6-hour change windows. Each sync copies the windows that are ready.

Once the passes have converged, incremental sync takes over.

How the handoff works

1. Before Pass 1, make sure the audit ingest of the source cluster is running (System Jobs > Schedules > ECS Ingest (SSH)). The writes that land while the passes walk the bucket then appear as change windows, and incremental sync copies them later.
2. Run the Target Skip passes while the protection groups are in Preparation Mode, until the copied count is near zero.
3. Open Cyber Vault > Vault Operations > Vault Data Sync Dashboard > Settings. Enable Incremental Sync and Smart Skip.
4. On the Sync Windows tab, click Sync Group Now for each group. Check that its windows reach Done. In the day slots of the week view, the status is Synced N.
5. Give each protection group its Schedule Policy. Create policies under Source Data Protection Group Config > Sync Schedules.
6. Click Switch to Vault Mode in the Operational Mode panel. From then on, the vault agent syncs each group on its schedule.
7. Stop running Target Skip passes. Incremental sync is now the steady state. Watch the Sync Windows tab for windows shown as Failed, Abandoned, or Partial. The same Failed and Partial labels appear in the day slots of the week view.

Smart Skip skips a changed object when its source ETag matches the last successful copy of that key by any earlier job, full sync or incremental. Change windows that overlap the passes therefore do not re-copy what the passes already copied.

A window shows Waiting for ingest until the audit ingest has read all of its events.

Target Skip pass compared with incremental sync

	Target Skip pass	Incremental sync
Scope	Lists the whole source bucket and compares every object with the target.	Copies only the objects in the change windows built from the ingested audit events. There is no walk.
How it starts	By hand from Full Data Sync Management > Vault Jobs > Start Full Sync. Not available for groups in Vault Mode.	With Sync Group Now in Preparation Mode. In Vault Mode the vault agent starts it on the group's schedule.
What it relies on	The skip tiers you choose in the dispatch dialog.	An up-to-date audit ingest. A window is synced only once the ingest has caught up past its end.

Tips

• Always know Y before launching Pass 1 of Scenario A or B. Ask the customer to confirm the install date in writing. The false-skip risk falls on the operator if the cutoff date is wrong.
• Run passes back to back. Each new pass is cheaper than the last, because Tier 2 absorbs more of the copies made by earlier passes.
• Stop running new passes when the copied count is near zero. Convergence is the signal that the walk has done all it can. Incremental sync takes over from there.
• Switch to Vault Mode only after the passes. A full sync cannot be started for a group in Vault Mode. Use Exit Vault Mode if you need another pass.
• Dispatch several buckets at once. Select multiple policies on Full Data Sync Management > Vault Jobs and click Start Full Sync to apply the same Target Skip configuration to all of them.
• Check the per-tier breakdown after each pass. Open the job in Copy Jobs - Live View & History, then Job #N Details > Target Skip Mode — per-tier breakdown. It shows how many objects each tier skipped, so you can verify that your tier choices made sense.