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