Huge resource utilization on servers Poor templates for managing filtering/reporting. High noise/signal ratio Etc...
-sc > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Tuesday, February 23, 2010 6:02 PM > To: NT System Admin Issues > Subject: Re: Archive data > > Really? How so? > > On Tue, Feb 23, 2010 at 14:56, Steven M. Caesare <[email protected]> > wrote: > > Yes. Evil. > > > > -sc > > > > -----Original Message----- > > From: David Lum [mailto:[email protected]] > > Sent: Tuesday, February 23, 2010 5:54 PM > > To: NT System Admin Issues > > Subject: RE: Archive data > > > > You guys had Tripwire? We have it here...rarely used as near as I can > > tell... > > > > -----Original Message----- > > From: Steven M. Caesare [mailto:[email protected]] > > Sent: Tuesday, February 23, 2010 2:53 PM > > To: NT System Admin Issues > > Subject: RE: Archive data > > > > You know, if we had kept our Tripwire installation.... > > > > Scratch that... I'd be in the looney bin... > > > > -sc > > > > -----Original Message----- > > From: Kurt Buff [mailto:[email protected]] > > Sent: Tuesday, February 23, 2010 3:04 PM > > To: NT System Admin Issues > > Subject: Re: Archive data > > > > So, you didn't examine your detailed backup logs to see the timestamp, > size and MD5/SHA1 hash of each file and see what hadn't changed in the past > 1/3/5 years? > > > > JK - mostly... > > > > Kurt > > > > On Tue, Feb 23, 2010 at 07:26, Steven M. Caesare > <[email protected]> wrote: > >> 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/> ~ > > > > ~ 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/> ~
