I got the impression that they ported it over with little regard for the differences in how the OS's behave, what conventions are used, etc...
-sc > -----Original Message----- > From: Kurt Buff [mailto:[email protected]] > Sent: Wednesday, February 24, 2010 1:24 PM > To: NT System Admin Issues > Subject: Re: Archive data > > 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/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
