Bummer. It's really well respected in the Unix world. I wonder if they've bungled the port.
On Wed, Feb 24, 2010 at 05:19, Steven M. Caesare <[email protected]> wrote: > 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/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
