Joe--
We currently have an iseries using a V9000 for all of our storage. The V9000 is sort of like 50 gazillion thumb drives in a 2-rack-unit space. We upgraded from a V7000 with spinning disk and a smaller flash appliance.
We're using the Full System Copy Services Manager (formerly the Full System Flash Copy (FSFC)) Toolkit. This is a set of programs that makes backing up the system almost fun!
The process involves 3 LPARs:
- The toolkit runs in its own tiny LPAR (running IBM i). It just needs enough resources to wake up and run a few commands/programs.
- The production LPAR being backed up
- A "Flash Copy" LPAR to hold the data being backed up (this is a 'thinly provisioned' LPAR)
Before we run our backup we start a Job Watcher (STRJW) on the production LPAR. This is probably not needed, but it runs about 45 minutes, long enough to watch the prep work and the actual flash of the production LPAR.
We then run a CHGASPACT ASPDEV(*SYSBAS) OPTION(*FRCWRT) (also on the production LPAR). This tells IBM/i to take any stray data that hasn't been written from the I/O buffers to 'disk' to do so. We do this because back on the V7000 running the data flash was taking longer than we liked. This means that when we actually flash the production LPAR there shouldn't be as much work to do. We give the system about 5 minutes to do this.
We then do some housekeeping on the production LPAR for tape cartridges and other odds'n'ends. This includes updating a file of the tapes in the tape library so the flashed partition know which tapes are available. We're not using IBM's BRMS. If we need to send any data to the flashed LPAR we just create the needed object in the LPAR to be backed up, and it's re-created in the flashed LPAR.
Then we run some commands on the FSFC Toolkit LPAR:
- Some housekeeping commands, including
- CHKIN a flag that locks the toolkit's use of the production LPAR
- CHKIN a flag that locks the toolkit's use of the Flash LPAR
- MKSYSCPY "MAKE SYSTEM COPY" This does the dirty work! It talks to the HMC (Hardware Management Console) to:
- Quiesce the production LPAR. All writes to disk are suspended. All pending writes are forced to 'disk'
- Once the LPAR is quiesced, it makes the flash copy.
- The production LPAR is released; disk operations continue from the point where they were suspended.
The MKSYSCPY performs its magic in about 2 minutes. For most users, they aren't aware of the suspended disk operations.
There are few, however, who will notice that the ENTER key they pressed takes a long time...
- The Flash Copy LPAR is now IPLd. The toolkit re-assigns comm line names and addresses to avoid conflicts, and activates a 'flash-copy only' link.
Once the flash copy LPAR is IPLd, we run an Option/21 backup every night! It's very nice-- we only used to get an Option/21 every 3 years when we upgraded the operating system!
There's a helpful user community (including the author of the FSFC (Now called the Full System Copy Services Manager) at
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Advanced%20Copy%20Services/page/Full%20System%20Copy%20Services%20Manager%20%28FSCSM%29
How does the flash actually work? FM... It does not actually duplicate all of the data! The flash all takes place in the V9000; the iSeries shouldn't know it's even happening! The V9000 creates a bitmap for each block of storage in the production LPAR. This has nothing to do with physical files, records, objects; it's just a block of storage. The Flash LPAR doesn't have any real data in it-- until either the production or flash LPAR changes something.
If the production LPAR updates something, a copy of the affected blocks is duplicated into the flash LPAR, and the bitmap is flagged to indicate that the data in those blocks has been duplicated in the flash copy.
Likewise, when the flash LPAR updates something, the data is duplicated into the flash LPAR before the data is touched-- and the flash copy is updated.
This is how you can have 2 copies of the data-- the flash copy is frozen at the moment the MKSYSCPY runs; the production LPAR can continue to run as normal. Because the system has to check the bitmap before it can access any data, there is some overhead. But this is minimal compared to shutting down an LPAR to do a backup!
Paul E Musselman
PaulMmn@xxxxxxxxxxxxx
.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Thursday, August 24, 2017 3:18 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Where do I learn about SAN backup?
I'm hearing that SAN storage allows us to do a very fast "snapshot" of
the system and then backup from that snapshot. It's supposed to make
the backup less intrusive. Is anyone doing something like this?
Thanks in advance!
midrange.com
