[00:00] <penguin42> oh, firmware upgrades; that doesn't surprise me at all - people are bad enough using old applications and OSs
[00:01] <daftykins> :D
[00:07] <daftykins> so now we're only left with all the services with errors that the boss has no idea have not been working!
[00:09] <penguin42> daftykins: I did go to a talk once by people doing a cross-continent data centre move where they had to basically replicate it at the new site and then cut over;  the hard job was figuring out wth was actually in the exisitng one
[00:10] <daftykins> :D
[00:10] <daftykins> that's been me, blind going in - slowly unpicking things
[00:14] <daftykins> though i don't actually admin Windows domains typically, which is why i'm steering these folks off one :D
[00:59] <daftykins> well, unsurprisingly it really flies now
[00:59] <daftykins> just got a defrag of C: to finish and it'll be about as good as it'll get on the current RAID :)
[06:09] <brobostigon> morning
[06:10] <zmoylan-pi> o/
[06:13] <brobostigon> \o
[07:57] <Gargoyle> o/
[08:00] <brobostigon> o/
[15:47] <daftykins> well i am feeling pretty smug after that, check out these metrics for that server - https://i.imgur.com/cbUnq4v.png
[15:54] <penguin42> heck, that write is much better!
[15:55] <daftykins> i was getting this prompt on first login (to Windows Server) about some maintenance task that needed to be run, too - so i did that and now the system no longer consumes all its' RAM for the MS Exchange process after boot
[15:56] <daftykins> it's so much more responsive, a browser comes up in 4 seconds instead of several minutes when i first visited them
[15:56] <daftykins> so this all began with "our backups keep running slower and slower after an office move", their old IT firm kept just blaming the server's age and saying well, it's all going EOL so you just need to replace it
[15:56] <daftykins> which is true, but wasn't even remotely true
[15:57] <daftykins> er, swap the second 'true' for 'relevant' :D
[15:57] <penguin42> what did the 'office move' actually do?
[15:58] <daftykins> the IT firm were paid to assist, one of the 3 RAID member disks popped during or soon after, so it could've been handled badly - but on setting things up they plugged everything into 100 Mb switch ports instead of gigabit ones
[16:08] <penguin42> was that network storage?
[16:09] <daftykins> nah the HP ML350p has an integrated P420i SATA/SAS HBA with the 3 x 300GB 10,000 RPM SAS disks
[16:10] <daftykins> oh i see what you mean, duh - yeah one of the backups was to a NAS
[16:10] <daftykins> then the other was to a 2.5" HDD over USB 2.0 on a spare core 2 duo PC thrown on a shelf beside the server xD
[16:10] <daftykins> all 100Mb when i got there :D
[16:11] <penguin42> was the backup COW - or else why was the write performance so changed?
[16:13] <daftykins> when moving to gigabit?
[16:13] <penguin42> yeh
[16:13] <penguin42> I mean if the storage was on local SAS why did it get faster?
[16:13] <daftykins> it was doing a block analysis against the existing dump on the remote share, so i think its' ability to check was pretty hampered
[16:14] <daftykins> the software for the backup should never have been installed on the VM itself, it's quite frankly laughable
[16:15] <penguin42> nod
[16:15] <daftykins> it shows some nice stats, it would only ever write at 5MB/sec when it was performing those backups
[16:16] <penguin42> nod, that's 50Mbps with the other 50 going to the backup I guess
[16:16] <daftykins> because it interrogates the VMware ESXi host directly over LAN too, i think essentially you had the program inside the VM looking out and at its' own host, then throwing over the network to the target - so it was insanely constrained
[18:39] <Chunkyz> K.