(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/> ~
