FlashCopy and Safeguarded Copy hands-on
DS8000 FlashCopy gives you a full copy of a volume in about a second while the application keeps running. Teams use it all the time, to refresh a test database from production, to take a copy before a risky upgrade, or to give the backup server something to read at night so production stays fast.
You’ll build all three kinds of FlashCopy in the practice shell: a one-time full copy, an incremental copy you can refresh, and a NOCOPY snapshot. Then you’ll restore production from a copy with reverseflash, set up Safeguarded Copy capacity, and get an honest picture of what the DS CLI can and can’t do for Safeguarded Copy.
You need the practice shell from Lesson 2, and if you’d like the theory first, Lesson 19 of the Architecture course explains the Copy Services family.
| Time | You need | By the end you can |
|---|---|---|
| 60 to 75 minutes | The SaatVedha practice shell and the setup script below | Create, refresh, restore and remove FlashCopy pairs, read lsflash, and set up Safeguarded Copy backup capacity |
What it is, in one line
FlashCopy makes an instant point-in-time copy of a volume on the same DS8000. Safeguarded Copy uses the same engine to keep many hidden backups that can’t be changed, and only Copy Services Manager or GDPS can create and recover them.
In Simple Words
A photo of the class blackboard
Your teacher fills the blackboard with notes and you take a photo with your phone. Click, and it’s done in a second, so you have the notes as they were at 10:15 even if the teacher wipes the board at 10:16.
The phone didn’t copy the board letter by letter; it froze that moment, and later you can print the photo slowly, page by page if you like, which is the background copy. The next week you take another photo and the phone saves only what changed since the last one, and that’s an incremental copy.
Safeguarded Copy is like the school office keeping the photos in a locked cupboard, where students can’t delete them or draw on them, and only the head teacher with a special key can take one out to restore the board.
Engineer's View
How FlashCopy really works on the DS8000
The bitmap. When you run mkflash source:target, the DS8000 creates a relationship and a bitmap of tracks, and the target is ready for reads and writes straight away.
If a host reads a target track that hasn’t been copied yet, the DS8000 reads it from the source. If a host writes to a source track that hasn’t been copied yet, the old track goes to the target first (copy on write).
Copy modes. The default -cp starts a background copy of every track, and once it finishes, a non-persistent relationship ends on its own. -nocp copies only the tracks that change on the source, which makes it a cheap snapshot. -record makes an incremental (type 1) relationship that tracks changes on both sides and switches on -persist, so the pair stays until you run rmflash.
Rules. Source and target have to be the same kind (FB or CKD) and the target at least as big, and on FB both must be T10-DIF or both standard. A source can have up to 12 FlashCopy relationships, but only one of them can be type 1 incremental.
A target can only be in one relationship. Repeat -record -persist on every resyncflash, otherwise the pair stops being incremental.
Restore. reverseflash copies the target back onto the source, and you still type the pair in its original order. Use -fast (Fast Reverse Restore) when the background copy hasn’t finished. -tgtinhibit blocks host writes to the target, and -freeze together with unfreezeflash gives you a consistent group across volumes.
Licence. FlashCopy comes under the Copy Services licence, and you count source plus target as provisioned capacity, so a 10 TB source needs a 20 TB licence.
Safeguarded Copy. It’s built on FlashCopy and keeps many protected backups (up to 1,024 per volume since Release 10.1). On the DS CLI all you manage is the backup capacity, using managefbvol or manageckdvol with -action mksafeguardedcap, expandsafeguardedcap, rmsafeguardedcap or migsafeguardedcap.
The capacity is the source size × -multiplier, at least 1.5, up to 16 TiB per FB volume and 14.6 TiB per CKD volume. Creating, expiring and recovering backups happens only in IBM Copy Services Manager (CSM 6.2.3 or later) or GDPS (4.2 or later), and there’s no mksafeguardedcopy command.
How it works, step by step
Take a real job as the example. The bank’s test team wants a fresh copy of production database volume 2204 on volume 2205 every Monday morning, and production mustn’t stop.
1mkflash creates the relationship
You run mkflash 2204:2205, and in under a second the DS8000 builds a bitmap with one bit for each track of the source, every bit saying “not copied yet”.
From that moment the target holds the point-in-time image, and a host can mount 2205 right away, even though no data has moved.
2Reads and writes during the copy
If someone reads a track on 2205 that hasn’t been copied yet, the DS8000 quietly fetches it from 2204. If production writes to a track on 2204 that hasn’t been copied yet, the old version goes to 2205 first and then the new write goes ahead.
So the copy always shows the data as it was at the moment you ran mkflash.
3The background copy finishes
With the default -cp, the DS8000 also copies every track in the background, and you’ll see OutOfSyncTracks in lsflash -l count down to 0.
At that point a plain mkflash relationship ends on its own and 2205 becomes an ordinary, independent volume.
4Incremental: copy only the changes next time
Copying 20 GiB every Monday is wasteful when only 1 GiB has changed. With mkflash -record -persist, the pair stays in place after the copy and the DS8000 keeps a record of which tracks change.
The following Monday you run resyncflash -record -persist 2204:2205, and only the changed tracks get copied.
5NOCOPY for short-lived snapshots
mkflash -nocp skips the background copy, so only tracks that change on the source are saved on the target, which keeps the space and back-end work small.
It suits a backup server that reads the target for two hours before you remove the pair. Just don’t ever treat a NOCOPY target as a full, independent copy.
6Restore with reverseflash
Say a bad upgrade corrupts production. If the pair was made with -record, reverseflash 2204:2205 copies the saved image back onto 2204, and you type the pair in its original order.
Stop the application and unmount the source before you do this.
7Safeguarded Copy: same engine, different owner
Safeguarded Copy keeps many backups of a source in hidden backup capacity that hosts can’t see or change.
On the DS8000 you prepare that capacity with managefbvol -action mksafeguardedcap, and from then on Copy Services Manager (or GDPS on IBM Z) takes the backups on a schedule, expires old ones, and recovers one to a recovery volume when you need it.
Hands-on lab: copy, refresh and restore with FlashCopy
Before you run any command, double-check it
Read every command twice before you press Enter. Check the target: the system or account, the IDs, the names and the sizes. These commands are for learning and were tested in our lab, not on your system. At work, run the read-only list commands first, follow your change process, make sure a backup exists, and ask a second person to check anything that changes or deletes data. You run them at your own risk.
Your lab system has a production database volume 2204 (mapped to saat-host1), a dev copy target 2205, a backup target 2207 and a small test volume 2206. You’ll copy, refresh, snapshot and restore, and then set up Safeguarded Copy capacity.
Practice shell note: the practice shell is our own teaching tool, not IBM software. Real DS CLI output looks very close to this but isn’t identical. Lines starting with SIM or “Note (practice shell)” are ours, and so are the IDs CMUN03023E and CMUN03027E. The shell copies a full volume in 2 simulated minutes, and simctl tick moves the clock on.
1Start clean and load the setup script
Save this as setup-18.txt in your lab folder.
setup-18.txt:
# setup-18.txt: pools, a production volume, FlashCopy targets and one host for Lesson 18
mkarray -raidtype 6 -arsite S1
mkarray -raidtype 6 -arsite S2
mkarray -raidtype 6 -arsite S7
mkarray -raidtype 6 -arsite S8
mkrank -array A0 -keygrp 1 -stgtype fb
mkrank -array A1 -keygrp 1 -stgtype fb
mkrank -array A2 -keygrp 1 -stgtype fb
mkrank -array A3 -keygrp 1 -stgtype fb
mkextpool -rankgrp 0 -keygrp 1 -stgtype fb FB_0
mkextpool -rankgrp 1 -keygrp 1 -stgtype fb FB_1
mkextpool -rankgrp 0 -keygrp 1 -stgtype fb T2_0
chrank -extpool P0 R0
chrank -extpool P1 R1
chrank -extpool P2 R2
chrank -extpool P2 R3
mkfbvol -extpool p2 -cap 20 -name proddb_#h 2204
mkfbvol -extpool p2 -cap 20 -name devdb_#h 2205
mkfbvol -extpool p2 -cap 20 -name bkp_#h 2207
mkfbvol -extpool p2 -cap 10 -name test_#h 2206
mkhost -type "Linux Server" -hostport 10000090FA13B914,10000090FA13B915 saat-host1
chhost -action map -volume 2204 saat-host1
simctl login 10000090FA13B914 I0032
simctl login 10000090FA13B915 I0042Run this:
python ds8sim.py (then: simctl reset, quit)
python ds8sim.py -hmc1 10.0.0.1 -user admin -script setup-18.txt
python ds8sim.pyWhen the script ends with two SIM0103I lines, check the volumes:
Run this:
lsfbvolYou should see this:
dscli> lsfbvol
Date/Time: 24 October 2026 10:57:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name ID accstate datastate configstate deviceMTM datatype extpool cap (2^30B) cap (10^9B) cap (blocks)
===============================================================================================================
proddb_2204 2204 Online Normal Normal 2107-900 FB 512 P2 20.0 - 41943040
devdb_2205 2205 Online Normal Normal 2107-900 FB 512 P2 20.0 - 41943040
test_2206 2206 Online Normal Normal 2107-900 FB 512 P2 10.0 - 20971520
bkp_2207 2207 Online Normal Normal 2107-900 FB 512 P2 20.0 - 41943040✅ Checkpoint: four volumes in P2: 2204, 2205 and 2207 at 20 GiB, 2206 at 10 GiB.
2Make a full copy for the test team
Run these:
mkflash 2204:2205
lsflash -l 2204:2205You should see this:
dscli> mkflash 2204:2205
CMUC00137I mkflash: FlashCopy pair 2204:2205 successfully created.
dscli> lsflash -l 2204:2205
Date/Time: 24 October 2026 10:57:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID SrcLSS SequenceNum Timeout ActiveCopy Recording Persistent Revertible SourceWriteEnabled TargetWriteEnabled BackgroundCopy SGC Recovered OutOfSyncTracks DateCreated DateSynced State isTgtSE
====================================================================================================================================================================================================================
2204:2205 22 0 120 Enabled Disabled Disabled Disabled Enabled Enabled Enabled no 327677 Sat Oct 24 10:57:10 2026 - Valid UnknownRead the row. ActiveCopy Enabled tells you the background copy is running, and since Recording and Persistent are Disabled, this is a one-time copy.
OutOfSyncTracks shows how many 64 KiB tracks are still left to copy, and 20 GiB is about 327,680 tracks.
✅ Checkpoint: lsflash shows 2204:2205 with ActiveCopy Enabled.
3Let the copy finish
Run these:
simctl tick 3
lsflash -l 2204:2205You should see this:
dscli> simctl tick 3
SIM0112I simctl: clock advanced 3 minutes.
dscli> lsflash -l 2204:2205
CMUC00234I lsflash: No Flash Copy found.The relationship has gone, and that’s normal: a non-persistent pair ends once the background copy is done, and 2205 is now an independent 20 GiB copy. People often panic at this point and think the copy failed.
✅ Checkpoint: lsflash says No Flash Copy found.
4Make it incremental for next week
Run these:
mkflash -record -persist 2204:2205
simctl tick 3
lsflash -l 2204:2205You should see this:
dscli> mkflash -record -persist 2204:2205
CMUC00137I mkflash: FlashCopy pair 2204:2205 successfully created.
dscli> simctl tick 3
SIM0112I simctl: clock advanced 3 minutes.
dscli> lsflash -l 2204:2205
Date/Time: 24 October 2026 11:03:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID SrcLSS SequenceNum Timeout ActiveCopy Recording Persistent Revertible SourceWriteEnabled TargetWriteEnabled BackgroundCopy SGC Recovered OutOfSyncTracks DateCreated DateSynced State isTgtSE
==================================================================================================================================================================================================================================
2204:2205 22 0 120 Disabled Enabled Enabled Disabled Enabled Enabled Enabled no 0 Sat Oct 24 11:00:10 2026 Sat Oct 24 11:03:10 2026 Valid UnknownThis time Recording and Persistent are Enabled, so after the copy the pair stays with OutOfSyncTracks 0 and a DateSynced time, and the DS8000 keeps track of every change on 2204.
✅ Checkpoint: 2204:2205 shows Recording Enabled, Persistent Enabled, OutOfSyncTracks 0.
5Refresh the copy (only the changes)
Production carries on working, and simctl io pretends the host wrote to 2204. Then refresh the copy, repeating -record -persist.
Run these:
simctl io 2204 40
resyncflash -record -persist 2204:2205
lsflash 2204:2205You should see this:
dscli> simctl io 2204 40
SIM0101I simctl: host I/O recorded on volume 2204 (in use for the next 5 minutes).
dscli> resyncflash -record -persist 2204:2205
CMUC00168I resyncflash: FlashCopy volume pair 2204:2205 successfully resynchronized.
dscli> lsflash 2204:2205
Date/Time: 24 October 2026 11:03:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID SrcLSS SequenceNum Timeout ActiveCopy Recording Persistent Revertible SourceWriteEnabled TargetWriteEnabled BackgroundCopy
====================================================================================================================================
2204:2205 22 0 120 Enabled Enabled Enabled Disabled Enabled Enabled EnabledActiveCopy turns Enabled again while the changed tracks are copied, and Recording stays Enabled, so next week’s refresh will be incremental too.
✅ Checkpoint: resyncflash prints CMUC00168I and Recording is still Enabled.
6Add a NOCOPY snapshot for the backup server
Run these:
mkflash -nocp 2204:2207
lsflash 2204You should see this:
dscli> mkflash -nocp 2204:2207
CMUC00137I mkflash: FlashCopy pair 2204:2207 successfully created.
dscli> lsflash 2204
Date/Time: 24 October 2026 11:03:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID SrcLSS SequenceNum Timeout ActiveCopy Recording Persistent Revertible SourceWriteEnabled TargetWriteEnabled BackgroundCopy
====================================================================================================================================
2204:2205 22 0 120 Enabled Enabled Enabled Disabled Enabled Enabled Enabled
2204:2207 22 0 120 Disabled Disabled Disabled Disabled Enabled Enabled DisabledThe source now has two relationships. The 2207 row shows BackgroundCopy Disabled, meaning only tracks that change on 2204 get saved there. The backup server reads 2207 tonight, and tomorrow you remove the pair with rmflash 2204:2207.
✅ Checkpoint: lsflash 2204 lists two pairs, and 2204:2207 has BackgroundCopy Disabled.
7Restore production from the copy
Pretend an upgrade has broken the database on 2204. The application team stops the database and unmounts the disk, and you restore from the incremental copy on 2205.
Run these:
simctl tick 3
reverseflash 2204:2205
lsflashYou should see this:
dscli> simctl tick 3
SIM0112I simctl: clock advanced 3 minutes.
dscli> reverseflash 2204:2205
CMUC00169I reverseflash: FlashCopy volume pair 2204:2205 successfully reversed.
dscli> lsflash
Date/Time: 24 October 2026 11:06:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID SrcLSS SequenceNum Timeout ActiveCopy Recording Persistent Revertible SourceWriteEnabled TargetWriteEnabled BackgroundCopy
====================================================================================================================================
2204:2207 22 0 120 Disabled Disabled Disabled Disabled Enabled Enabled Disabled
2205:2204 22 0 120 Disabled Enabled Enabled Disabled Enabled Enabled EnabledThe pair now reads 2205:2204, because 2205 is the source and its image has been copied back onto 2204. On a real system you’d mount 2204 now and check the data before starting the application.
✅ Checkpoint: lsflash shows 2205:2204.
8Prepare Safeguarded Copy capacity
Give 2204 backup capacity of twice its size in pool P2. That’s all the DS CLI does for Safeguarded Copy.
Run these:
managefbvol -action mksafeguardedcap -extpool P2 -multiplier 2 2204
showfbvol 2204You should see this:
dscli> managefbvol -action mksafeguardedcap -extpool P2 -multiplier 2 2204
CMUC00430I managefbvol: The mksafeguardedcap action for FB volume 2204 has completed.
dscli> showfbvol 2204
Date/Time: 24 October 2026 11:06:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
Name proddb_2204
ID 2204
extpool P2
cap (2^30B) 20.0
cap (blocks) 41943040
volgrp V0
sam Standard
safeguardedcap (2^30B) 40.0
safeguardedloc P2
usedsafeguardedcap (2^30B) 0.0
safeguarded no
SGC Recovered no
(output shortened)safeguardedcap shows 40.0 GiB (20 × 2) in safeguardedloc P2, none of it used yet, and safeguarded no means no backups exist. The backups come from Copy Services Manager or GDPS, never from the DS CLI.
✅ Checkpoint: showfbvol 2204 shows safeguardedcap (2^30B) 40.0.
9What happens next, in Copy Services Manager
On a real system you’d open CSM, create a Safeguarded Copy session, add 2204 as a source and set a schedule (every 4 hours, keep 7 days, for example). CSM then runs Backup and Expire Backup, and when you need it, Recover to a separate recovery volume that you check before you restore.
✅ Checkpoint: you can say which tasks belong to the DS CLI (capacity) and which to CSM or GDPS (backups and recovery).
Break It, Then Fix It
Stay in the same session. These two FlashCopy mistakes cost teams the most time: picking the wrong target size, and a refresh that quietly stops being incremental.
1Break it: copy onto a target that is too small
The test team wants a copy of 2204 on the spare volume 2206, so try it.
Run this:
mkflash -record -persist 2204:2206You’ll get this error:
dscli> mkflash -record -persist 2204:2206
CMUN03023E mkflash: 2204:2206: The target volume must be the same type and at least the same size as the source volume.Why: 2206 is 10 GiB and 2204 is 20 GiB, and a FlashCopy target has to be the same type and at least as large as the source. (The ID is a practice shell message, but a real DS8000 refuses too.)
Fix: grow the target to match. Since it isn’t mapped to any host, growing it is safe.
Run these:
chfbvol -cap 20 2206
mkflash -record -persist 2204:2206You should see this:
dscli> chfbvol -cap 20 2206
CMUC00332W chfbvol: Some host operating systems do not support changing the volume size. Are you sure that you want to resize the volume? [y/n]: y
CMUC00026I chfbvol: FB volume 2206 successfully modified.
dscli> mkflash -record -persist 2204:2206
CMUC00137I mkflash: FlashCopy pair 2204:2206 successfully created.✅ Checkpoint: mkflash -record -persist 2204:2206 prints CMUC00137I.
2Break it: refresh without -record -persist
A week later someone refreshes the copy from memory and types in only the pair.
Run these:
simctl tick 3
simctl io 2204 25
resyncflash 2204:2206
lsflash 2204:2206You get this, which looks fine but isn’t:
dscli> simctl tick 3
SIM0112I simctl: clock advanced 3 minutes.
dscli> simctl io 2204 25
SIM0101I simctl: host I/O recorded on volume 2204 (in use for the next 5 minutes).
dscli> resyncflash 2204:2206
CMUC00168I resyncflash: FlashCopy volume pair 2204:2206 successfully resynchronized.
Note (practice shell): -record was not repeated, so 2204:2206 is no longer incremental.
dscli> lsflash 2204:2206
Date/Time: 24 October 2026 11:09:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID SrcLSS SequenceNum Timeout ActiveCopy Recording Persistent Revertible SourceWriteEnabled TargetWriteEnabled BackgroundCopy
====================================================================================================================================
2204:2206 22 0 120 Enabled Disabled Disabled Disabled Enabled Enabled EnabledWhy: the refresh worked, but Recording and Persistent have now dropped to Disabled. IBM’s rule is to repeat -record -persist on every resyncflash, and if you leave them out the relationship stops being incremental, so next week’s refresh fails:
Run this:
resyncflash -record -persist 2204:2206You’ll get this error:
dscli> resyncflash -record -persist 2204:2206
CMUN03027E resyncflash: 2204:2206: The relationship was not created with -record -persist.Fix: remove the pair and create it again as incremental, then put the full command in your refresh script so nobody has to type it from memory.
Run these:
rmflash 2204:2206
mkflash -record -persist 2204:2206
lsflash 2204:2206You should see this:
dscli> rmflash 2204:2206
CMUC00144W rmflash: Are you sure you want to remove the FlashCopy pair 2204:2206? [y/n]: y
CMUC00140I rmflash: FlashCopy pair 2204:2206 successfully removed.
dscli> mkflash -record -persist 2204:2206
CMUC00137I mkflash: FlashCopy pair 2204:2206 successfully created.
dscli> lsflash 2204:2206
Date/Time: 24 October 2026 11:09:10 UTC IBM DSCLI Version: 7.10.10.348 DS: IBM.2107-78SV001
ID SrcLSS SequenceNum Timeout ActiveCopy Recording Persistent Revertible SourceWriteEnabled TargetWriteEnabled BackgroundCopy
====================================================================================================================================
2204:2206 22 0 120 Enabled Enabled Enabled Disabled Enabled Enabled Enabled✅ Checkpoint: 2204:2206 shows Recording Enabled and Persistent Enabled again.
Bonus mistake. Try mksafeguardedcopy 2204 and the shell answers CMUN00014E mksafeguardedcopy: Unknown command., because there’s no such DS CLI command.
And -multiplier 1 on managefbvol fails with CMUN03052E (a practice shell message), since IBM requires at least 1.5.
This happened at work
The dev refresh that landed on the reporting database
A retail bank refreshed its development databases from production every Sunday night with a FlashCopy script, which worked from a list of pairs with the production LUN on the left and the dev LUN on the right. During a migration the reporting team got new volumes and some old dev volumes were reused, but nobody updated the script, so that Sunday mkflash copied production straight over a volume that now held the live reporting database.
The reporting system came up on Monday with Sunday’s production data sitting in its place, and that week’s regulatory reports were wrong.
FlashCopy had done what it was told. The target was the right size and not in any other relationship, so nothing stopped it, and the restore took a full day, with the reporting data coming back from backup tapes and the missing hours rebuilt from logs.
Root cause: a hard-coded target list that nobody owned, and no check that each target was still a dev volume. Fix: the script now reads showfbvol for every target and stops unless the volume name starts with dev_ and it’s mapped only to dev hosts. Targets also get -tgtinhibit, so no host can write to them by accident between refreshes.
The lesson: with FlashCopy the target loses everything it held in one second, so check it as carefully as you’d check a volume you’re about to delete.
Common mistakes and troubleshooting
| Symptom | Likely cause | What to check / fix |
|---|---|---|
| The pair “disappeared” from lsflash | A non-persistent copy (-cp, no -persist) finished | That’s normal. Use -record -persist if you’ll want to refresh it later. |
| resyncflash fails: not created with -record -persist | An earlier refresh left out -record -persist | Remove the pair and create it again with mkflash -record -persist, and put the flags in a script. |
| mkflash: target too small or wrong type | Target smaller than the source, FB vs CKD, or T10-DIF mismatch | Grow the target, or pick a volume that matches. |
| mkflash: target already a FlashCopy target | The target is in another relationship | Run lsflash on the target and remove the old pair first. |
| Backup from a NOCOPY target is “corrupt” after the pair was removed | A NOCOPY target holds only changed tracks | Keep the pair while you read from it, or use -cp to get an independent copy. |
| reverseflash refused | Pair not made with -record, or background copy not finished | Create any pair you might restore from with -record, and use -fast for Fast Reverse Restore. |
| Someone asks for “the DS CLI command to take a Safeguarded backup” | There isn’t one | Only capacity, with managefbvol; the backups and recovery happen in CSM or GDPS. |
Before any FlashCopy, read the target with showfbvol and ask yourself “what’s on this volume right now?”. Afterwards, read lsflash -l and check Recording, Persistent and OutOfSyncTracks.
Interview questions
Click a question to open it. Each one is worded the way an interviewer would ask it, and underneath you’ll find why they ask it and one way you could answer in your own words.
Fresher level
1. In simple words, what does FlashCopy do and why is it instant?
Why they ask this: They want to know you understand the bitmap idea and not only the command name.
How you might answer: FlashCopy makes a point-in-time copy of a volume on the same DS8000. It’s instant because at first the DS8000 only builds a bitmap of tracks, so the target is usable straight away and any read of an uncopied track comes from the source. If the source changes a track that hasn’t been copied yet, the old data goes to the target first.
2. What’s the difference between a normal FlashCopy and one made with -nocp?
Why they ask this: They’re checking you know which copies are independent and which aren’t.
How you might answer: A normal FlashCopy runs a background copy of every track, so once it finishes the target is a full, independent volume. With -nocp only the tracks that change on the source get copied, so the target depends on the source for as long as the pair exists. I’d use NOCOPY for short jobs like a nightly backup read.
2–5 years experience
3. Walk me through setting up a weekly dev refresh from a 2 TB production LUN.
Why they ask this: They want a real procedure with the right flags, the checks and the host side.
How you might answer: I’d first make sure the dev target is the same size, isn’t mapped to production hosts and isn’t in another relationship. The first run is mkflash -record -persist prod:dev, and I’d watch lsflash -l until OutOfSyncTracks reaches 0.
Every week the dev team stops their database, I run resyncflash -record -persist prod:dev so only the changed tracks copy, and they remount. The command sits in a script that checks the target’s name and mapping before it runs.
4. A colleague says “we have Safeguarded Copy, the DS CLI takes the backups every 4 hours”. Is that right?
Why they ask this: Plenty of people get the split of work wrong, and they want to see if you know it.
How you might answer: No. On the DS8000 the DS CLI only manages the backup capacity, with managefbvol or manageckdvol and -action mksafeguardedcap, using a multiplier of at least 1.5. The backups themselves, their schedule, expiry and recovery are handled by Copy Services Manager or GDPS.
So I’d find out which CSM session or GDPS policy is running the backups, and make sure someone is watching its alerts.
Senior level
5. A ransomware attack encrypted a production database last night. You have FlashCopy and Safeguarded Copy. How do you use them to recover?
Why they ask this: A senior person has to think about clean recovery points, testing before a restore, and not making things worse.
How you might answer: My first step would be to stop further damage and keep the corrupted volumes for forensics rather than overwrite them straight away. In CSM I’d recover the newest Safeguarded backup from before the attack to a separate recovery volume, mount it on an isolated host and let the app team check the data.
Once we trust a recovery point, we restore it to production, either from CSM or with a FlashCopy from the recovery volume. A daily FlashCopy on its own isn’t enough, because hosts can see and change it, so the attacker may well have hit it too.
6. How would you design FlashCopy for a database that spans 8 volumes so the copy is consistent?
Why they ask this: They want to see you understand consistency across volumes, not only single pairs.
How you might answer: If the database spans 8 volumes, they all have to be copied at the same point in time. I’d create the pairs in a single mkflash -freeze command with a sequence number, which holds I/O on the source LSSs for a moment, and run unfreezeflash on those LSSs straight after. Better still, put the database in backup mode first, or let CSM manage the group as a consistency group.
Quick quiz
Q1. You run mkflash 2204:2205 with no other flags. What happens when the background copy finishes?
- The pair stays forever
- The relationship ends and 2205 is an independent copy
- 2205 is deleted
- The copy starts again
Show answer
B: A non-persistent copy relationship ends once every track has been copied.
Q2. Which flags do you need so that resyncflash can refresh only the changed tracks?
- -nocp
- -tgtinhibit
- -record -persist
- -freeze
Show answer
C: Incremental FlashCopy needs -record (which also sets -persist), and you repeat them on every resyncflash.
Q3. How many FlashCopy relationships can one source volume have?
- 1
- 4
- 12, only one of them type 1 incremental
- Unlimited
Show answer
C: Up to 12, and only one of them can be type 1 incremental.
Q4. Which DS CLI command creates a Safeguarded Copy backup?
- mksafeguardedcopy
- managefbvol -action mksafeguardedcap
- mkflash -sgc
- None: backups are created by CSM or GDPS
Show answer
D: managefbvol only creates the backup capacity, and CSM or GDPS creates the backups.
Q5. What is the smallest -multiplier for Safeguarded backup capacity?
- 1.0
- 1.5
- 2.0
- 4.0
Show answer
B: IBM requires at least 1.5 so that at least one backup fits.
Quick recap
mkflashmakes an instant copy, and a plain copy ends once the background copy is done.-record -persistmakes it incremental, and you repeat both on everyresyncflash.-nocpsaves only the changed tracks, a cheap snapshot that depends on the source.reverseflashrestores the target onto the source; use-fastif the copy hasn’t finished.- The target loses its old data the moment you run mkflash, so check it first.
- Safeguarded Copy: DS CLI sets capacity (
managefbvol -action mksafeguardedcap -multiplier); CSM or GDPS takes and recovers the backups.
Next lesson
Lesson 19: Metro Mirror and Global Mirror: paths, pairs, failover → You mirror a volume to a second DS8000 and practise a failover and failback.
Further reading: DS8000 FlashCopy
Want to go deeper into DS8000 FlashCopy? IBM covers FlashCopy and Safeguarded Copy in the IBM Storage DS8000 Safeguarded Copy Redpaper (REDP-5506). For the big picture of all copy functions, see Copy Services map: FlashCopy, Metro Mirror, Global Mirror.
You can also see the full plan for this course on the IBM DS8000 Implementation course page.
Try it yourself: open the DS8000 FlashCopy command builder, type in the source and target, pick the copy mode, and it gives you mkflash and lsflash.