The place I used to intern with, they had a server that'd been in use since 1999. Almost constant use. It basically carried the weight of the entire place. All the corporate files were on it, including the accounts, .pst backups and account backups in case any of the company laptops - which dated to 2007/8 - failed on the road. Even then, the server had it's drives mirrored in RAID 1. I managed to convince them to make it properly redundant by having a simple automatic upload of the latest backup to spare space on our website host in case the server fell over, and erase the last one because space on the host was that tight and there was years of data in there.
I set it to do that late on Sundays, because it was the same place where our website was hosted and I didn't want to have it either down over the entire weekend, or go slow when people were trying to access it. And while the hosting agreement didn't specifically forbid us doing it , I didn't want to give them a reason to forbid it either.
(Before anyone screams 'You idiot'. I'm not an IT Professional or sysadmin, I don't officially work in IT, have no formal training or certifications, and I only did this because even I knew that the current setup was one fuckup away from falling over. It was something I hoped might give us a fighting chance if the server totally up and died. out of the three employees, I was the IT-guy by virtue of having hacked a new feature onto the company website)
One of the drives on the server decided to fail over the weekend while everyone was out, on a Saturday I guess. It didn't fail in a way that dropped it offline. It kept 'working' even as the thing was screaming, streaming out corrupted data. It streamed corrupted data all over its mirror, munging the backups. The main OS remained online, as it was on a separate disk. The job I'd set to run automatically on Sunday promptly read the corrupted files from the damaged RAID array, and dutifully uploaded them to the host after erasing the old backup because we just didn't have the space to keep them.
You can probably fill in the rest of what happened on Monday morning. Some of the mails still existed on the local machines - but archives and client-lists were ripped apart, along with some manuals and documentation - but the company accounts were mangled beyond repair.
The business fell over not long after that. While it'd been failing for a while - hence the reason why the hardware hadn't been upgraded or replaced - that was the thing that just tipped it right over the edge and the Directors pulled the plug after lurching onwards for another short while.
So it is entirely possible for backups to puke. Or be incompatible with changed variants of software, or have been lost to password changes. Or any number of things. It doesn't matter how 'by the numbers' things are done - IT failures will always find some way to propagate and always find that one hole you just didn't think of. Especially if something is automated, and is overseen by a person who thinks that because it's automated - they don't need to pay attention to it. And 'redundancy' means it has more of a chance to spread and propagate and update before anyone catches it.
The point being of all this is that, no matter how 'redundant' backups are, this still doesn't prove a coverup.
________________________________
--m(^0^)m-- Wot, no sig?
I set it to do that late on Sundays, because it was the same place where our website was hosted and I didn't want to have it either down over the entire weekend, or go slow when people were trying to access it. And while the hosting agreement didn't specifically forbid us doing it , I didn't want to give them a reason to forbid it either.
(Before anyone screams 'You idiot'. I'm not an IT Professional or sysadmin, I don't officially work in IT, have no formal training or certifications, and I only did this because even I knew that the current setup was one fuckup away from falling over. It was something I hoped might give us a fighting chance if the server totally up and died. out of the three employees, I was the IT-guy by virtue of having hacked a new feature onto the company website)
One of the drives on the server decided to fail over the weekend while everyone was out, on a Saturday I guess. It didn't fail in a way that dropped it offline. It kept 'working' even as the thing was screaming, streaming out corrupted data. It streamed corrupted data all over its mirror, munging the backups. The main OS remained online, as it was on a separate disk. The job I'd set to run automatically on Sunday promptly read the corrupted files from the damaged RAID array, and dutifully uploaded them to the host after erasing the old backup because we just didn't have the space to keep them.
You can probably fill in the rest of what happened on Monday morning. Some of the mails still existed on the local machines - but archives and client-lists were ripped apart, along with some manuals and documentation - but the company accounts were mangled beyond repair.
The business fell over not long after that. While it'd been failing for a while - hence the reason why the hardware hadn't been upgraded or replaced - that was the thing that just tipped it right over the edge and the Directors pulled the plug after lurching onwards for another short while.
So it is entirely possible for backups to puke. Or be incompatible with changed variants of software, or have been lost to password changes. Or any number of things. It doesn't matter how 'by the numbers' things are done - IT failures will always find some way to propagate and always find that one hole you just didn't think of. Especially if something is automated, and is overseen by a person who thinks that because it's automated - they don't need to pay attention to it. And 'redundancy' means it has more of a chance to spread and propagate and update before anyone catches it.
The point being of all this is that, no matter how 'redundant' backups are, this still doesn't prove a coverup.
________________________________
--m(^0^)m-- Wot, no sig?