This is hackery at it's worst, or best, depending on your point of view. This is how we got around the 8.7TB limit:
Backups were going to instance macc-4-1. Set up a new instance, macc-4-3, as a virtual volume instance. Set up a new devclass/stgpool on macc-4-1 to send virtual volumes to macc-4-3, max size 100G. Rob disk pool volumes from macc-4-1 and put them on macc-4-3. Set backups to go to the new virtual volume pool. Backups are still going to disk, just in a round-about way. Once they're to disk macc-4-3, they'll be migrated back to tape on macc-4-1 at our leisure, and hopefully not get preempted. I originally tried setting up all the virtual volume stuff within macc-4-1, but the TSM instance didn't like mounting virtual volumes off of itself. Hopefully this solution is temporary. -- Cameron Hanover [email protected] "Let's get dangerous." --Darkwing Duck On Jun 5, 2010, at 5:09 PM, Cameron Hanover wrote: > For what it's worth, after some go-rounds with IBM development, it appears > there's an 8.7TB limit being hit somewhere. That's why the backup is going > to tape rather than disk. They are currently investigating the ramifications > of removing this limit. > I'm working on a hair-brained workaround. If it works, I'll post it to list. > > - > Cameron Hanover > [email protected] > > "Chaos was the law of nature. Order was the dream of man." > --Henry Brooks Adams > > > > On May 17, 2010, at 8:45 AM, c.hanover wrote: > >> My understanding of an NDMP differential backup is that TSM assumes the >> backup will be the full size of the filesystem at the beginning of the >> backup, and places it accordingly. If that's the case, then that isn't >> true, because the backup of the other large filesystem on that NAS goes to >> disk, and it's a 5TB filesystem with 4TB of data. >> >> -- >> Cameron Hanover >> [email protected] >> >> "A computer once beat me at chess, but it was no match for me at kick >> boxing." >> --Emo Philips >> >> On May 15, 2010, at 5:00 AM, Remco Post wrote: >> >>> On DISK type storage, TSM can't split a transaction over multiple volumes, >>> you need FILE type storage to be able to do that. Since NDMP dumps are a >>> single transaction..... >>> >>> >>> On 14 mei 2010, at 17:29, c.hanover wrote: >>> >>>> Our setup: >>>> TSM 5.4.1.2 Server on Linux, a 19TB disk pool dedicated to the management >>>> class for the NAS node. The disk pool is largely made up of 1.8TB volumes >>>> on a RAID5, the maxfilesize is set to 'nolimit', highmig=100, lowmig=99. >>>> The NAS is a BlueArc, according to the trace: >>>> NAS Vendorname: BlueArc Corp. >>>> Productname: Silicon Server NDMP. >>>> Revisionnumber: 6.1. >>>> Hosttype: BOS. >>>> Versionnumber: 6.1. >>>> >>>> The filesystem in question: >>>> fsName=/__VOLUME__/cifpilot1, fsType=WFS, fsId=2, fsCap=10Tb, fsOcc=8650Gb >>>> >>>> When I perform a backup of that filesystem (backup node >>>> XXXXXXXXXXXXX.umich.edu /__VOLUME__/cifpilot1 toc=yes mode=diff), rather >>>> than go to the empty disk pool, it immediately goes to tape. This is >>>> causing a problem because the job is getting preempted when the scheduled >>>> migrations occur on the other servers at 7am. Other smaller filesystems >>>> (0.4 and 5TB, respectively) backup to disk just fine. >>>> I've moved the backup as early as I could to try and get it to complete >>>> before migrations, but that's not working anymore. I need to figure out >>>> why this backup is going to tape rather than to disk. >>>> >>>> Anybody have any ideas? >>>> >>>> - >>>> Cameron Hanover >>>> [email protected] >>>> >>>> "Necessity is the plea for every infringement of human freedom. It is the >>>> argument of tyrants; it is the creed of slaves." >>>> --William Pitt, House of Commons, 11/18/1783 >>> >>> -- >>> >>> Met vriendelijke groeten/Kind regards, >>> >>> Remco Post >>> >>> >> >
