Doh! Busy as all get out yesterday and didn't really have time to read all 756 new threads closely. My bad.
On Tue, Feb 23, 2010 at 11:14 AM, Steven M. Caesare <[email protected]>wrote: > (mumbles about Richie ignoring my previous msgs....) > > Here's my response to David in this thread just yesterday (you gettin' old, > Stovall?) > > > ------------------------------------------------------------------------ > From: Steven M. Caesare > Sent: Monday, February 22, 2010 4:18 PM > To: 'NT System Admin Issues' > Subject: RE: Archive data > > I’ll take a stab: > > We eval’ed Symantec Vault, and rolled out a very limited pilot. It was not > without its problems, including performance issues when accessing stubs on > larger files that needed to be rolled back in to the store. We abandoned the > project. > > We have since begun transitioning out backup architecture to CommVault, > which looks to be more mature, and have begun looking at their vaulting > product and leverages the existing backup/storage infrastructure nicely, but > currently haven’t gone in to pilot as of yet. > > -sc > > > > > -----Original Message----- > > From: Richard Stovall [mailto:[email protected]] > > Sent: Tuesday, February 23, 2010 11:09 AM > > To: NT System Admin Issues > > Subject: RE: Archive data > > > > What do you do/use to move the dusty bits to a different tier? Do you > have > > an automagic system with stubbing or pointers of some sort, or do you > just > > move it by hand and tell the users where it's gone off to? If the > latter, are > > the secondary and tertiary tiers end-user accessible, or is IT > intervention > > necessary? This is the part I've never been able to figure out how to do > > inexpensively/sanely. > > > > -----Original Message----- > > From: Steven M. Caesare [mailto:[email protected]] > > Sent: Tuesday, February 23, 2010 10:26 AM > > To: NT System Admin Issues > > Subject: RE: Archive data > > > > Toolset usage on soma samples (which did indeed taint that), and some on > > copies/restored samples. > > > > But the "don’t really know about the rest of it" was kind of the point. > We > > didn't sample ALL of the data, but a subset for each major type/class of > > users/data and extrapolated from there. > > > > It was enough to determine that a substantial amount of tier1 storage was > > for data that was old & dusty. > > > > -sc > > > > > -----Original Message----- > > > From: Kurt Buff [mailto:[email protected]] > > > Sent: Tuesday, February 23, 2010 10:09 AM > > > To: NT System Admin Issues > > > Subject: Re: Archive data > > > > > > How did you do your sampling? I'm thinking that you've either a) > > > turned instantiated nftsdisablelastaccessupdate in which case you > > > don't know or b) you've disturbed the last access time, in which case > > > you've tainted the sample data, at least, and don't really know about > the > > rest of it. > > > > > > But aside from that, if it's work product (so as to exclude mp3s, > > > etc.), and there isn't a data retention policy, why not just leave it > > > on primary storage, assuming that there is enough room to do so? > > > > > > Kurt > > > > > > > > > On Tue, Feb 23, 2010 at 06:56, Steven M. Caesare > > > <[email protected]> > > > wrote: > > > > Well, I assume that even looking at a subset, it may be obvious that > > > > for > > > something like user data, for example, that some large percentage of > > > it may be greater than several years old and not accessed in the last > > > 3 years (or whatever your threshold may be). > > > > > > > > We were pretty easily able to take a statistically valid sample of > > > > our data > > > and extrapolate out for a good amount if it, even if we didn't account > > > for the overall total. > > > > > > > > -sc > > > > > > > >> -----Original Message----- > > > >> From: Kurt Buff [mailto:[email protected]] > > > >> Sent: Tuesday, February 23, 2010 9:53 AM > > > >> To: NT System Admin Issues > > > >> Subject: Re: Archive data > > > >> > > > >> Uh, > > > >> > > > >> If you don't know how much storage there is, how do you know that > > > >> any of it needs to be archived? > > > >> > > > >> Just asking... > > > >> > > > >> On Tue, Feb 23, 2010 at 06:49, David Lum <[email protected]> > > wrote: > > > >> > Windows servers for file/print, and a *lot* of IBM SAN storage > > > >> > (about 4 > > > >> servers racks full - dunno how much storage it is since SE manages > > > >> it), which is ex$pen$ive to expand and far more than we need to > > > >> spend to keep users old crap. Functionally a 2TB RAID1 USB would be > > > >> sufficient. I'm thinking $1000 or less of NAS with a ROBOCOPY job > > > >> (pulling from six different servers or so) should be more than > sufficient. > > > >> > > > > >> > I have submitted a proposal, we'll see if it flies. > > > >> > > > > >> > Dave > > > >> > > > > >> > -----Original Message----- > > > >> > From: Kurt Buff [mailto:[email protected]] > > > >> > Sent: Monday, February 22, 2010 6:19 PM > > > >> > To: NT System Admin Issues > > > >> > Subject: Re: Archive data > > > >> > > > > >> > What is your current system? Hardware and OS? > > > >> > > > > >> > Is it using SCSI, SATA, SAS, PATA? Is it hardware RAID? Does it > hot > > swap? > > > >> > > > > >> > Frankly, if your hardware hot swaps, and it's SATA or SAS, it > > > >> > might be cheaper and more efficient to swap out disks one at a > > > >> > time, let the array rebuild and then expand your space. Once > > > >> > you've replaced the drives, Win2k3+ should recognize the new > > > >> > (unpartitioned) space, and allow you to expand the current > partition > > to fill it. > > > >> > > > > >> > As pointed out, if they can't say for sure that they don't need > > > >> > it, then they probably *do* need it. > > > >> > > > > >> > Kurt > > > >> > > > > >> > On Mon, Feb 22, 2010 at 13:09, David Lum <[email protected]> > > > wrote: > > > >> >> Wow - nobody? > > > >> >> > > > >> >> > > > >> >> > > > >> >> From: David Lum [mailto:[email protected]] > > > >> >> Sent: Thursday, February 18, 2010 8:18 AM > > > >> >> To: NT System Admin Issues > > > >> >> Subject: Archive data > > > >> >> > > > >> >> > > > >> >> > > > >> >> Do any of you guys have an automated method for migrating old, > > > >> >> unused user data off your primary servers? I’m talking about > > > >> >> data users don’t want to have deleted, but they maintain for “I > > > >> >> might need it > > > >> someday” purposes. > > > >> >> > > > >> >> > > > >> >> > > > >> >> To accommodate this I would think a cheap RAID1 NAS should be > > > >> >> sufficient, there is no need for high-speed, multiple user > access. > > > >> >> I’m thinking it would be a very cheap way to pull a TB or so off > > > >> >> our > > > SAN…. > > > >> >> > > > >> >> David Lum // SYSTEMS ENGINEER > > > >> >> NORTHWEST EVALUATION ASSOCIATION > > > >> >> (Desk) 971.222.1025 // (Cell) 503.267.9764 > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> > > > > >> > ~ Finally, powerful endpoint security that ISN'T a resource hog! > > > >> > ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> > > > >> > ~ > > > >> > > > > >> > > > > >> > > > > >> > ~ Finally, powerful endpoint security that ISN'T a resource hog! > > > >> > ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> > > > >> > ~ > > > >> > > > >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > > > >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > > > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
