when I say we store and handle a lot of data for a YouTube channel I mean it I
mean we've built some sick 100 plus terabyte servers for some of our fellow
YouTubers but those are nothing compared
to the two plus petabytes of archival
storage that we currently have in production in our server room that is
storing all the footage for every video we have ever made at full quality
for the uninitiated that is over 11
000 Warzone installs worth of data but with great power comes great
responsibility and we weren't responsible
despite our super dope Hardware we made
a little oopsie that resulted in us permanently losing data that we don't
have any backup for we still don't know how much but what we do know is what
went wrong and we've got a plan to recover what we can but it is going to
take some work and some money thanks to our sponsor hetzner hetzner offers high
performance Cloud servers for an amazing price with their new Us location in
Ashburn Virginia you can deploy Cloud servers in four different locations and
benefit from features like load balancers block storage and more use
code ltt22 at the link below for twenty dollars off
foreign
let's start with a bit of background on our servers our archival storage is
composed of two discrete cluster ffs clusters both of them spread across two
45 drives storinator servers each with
60 hard drives the original petabyte
project is made up of the Delta 1 and Delta 2 servers and goes by the moniker
old Vault petabyte project 2 or the new
vault is Delta 3 and Delta IV now
because of the nature of our content most of our employees are pretty Tech
literate with many of them even falling into the tech wizard category so we've
always had substantially lower need for tech support than the average company
and as a result we have never hired a full-time it person despite the handful
of times perhaps including this one that it probably would have been helpful
so in the early days I managed the
infrastructure and since then I've had some help from both outside sources
and other members of the writing team
we all have different strengths but what
we all have in common is that we have other jobs to do meaning that it's never
really been clear who exactly is
supposed to be accountable when something slips through the cracks
and unfortunately while obvious issues
like a replacement power cable and a handful of failed drives over the years
were handled by Anthony we never really tasked anyone with performing
preventative maintenance on our precious petabyte servers a quick point of
clarification before we get into the rest of this nothing that happened is
the result of anything other than us messing up the hardware both from 45
drives and from Seagate Who provided the bulk of what makes up our petabyte
project servers has performed beyond our expectations and we would recommend
checking out both of them if you or your business has serious data storage needs
we're going to have links to them down below but even the Best Hardware in the
world can be let down by misconfigured software and Jake who tasked himself
with auditing our current infrastructure found just such a thing
everything was actually going pretty well he was setting up monitoring and
alerts verifying that every machine would gracefully shut down when the
power goes out which happens a lot here for some reason but he eventually worked
his way around to the petabyte project servers and checked the status of the
ZFS pools or Z pools on each of them and
this is where the Kaka hit the fan right off the bat Delta one had two of its 60
drives faulted in the same v-depth and you can think of a v-dev kind of like
its own mini raid array within a larger
pool of multiple raid arrays so in our
configuration where we're running raid Z2 if another disc out of our 15 Drive
v-dev was to have any kind of problem we would incur irrecoverable data loss upon
further inspection both of the drives were completely dead which does happen
with mechanical devices and had dropped from the system so we replaced them and
let the array start rebuilding that's pretty scary but not in another itself a
lost cause more on that later though far scarier
was when Delta 3 which is part of the new Vault cluster had five drives in a
faulted state with two of the V devs having two drives down that's very
dangerous interestingly these drives weren't
actually dead instead they had just faulted due to having too many errors so
read and write errors like this are usually caused by a faulty cable or
connection but they can also be the sign of a Dying Drive in our case these
errors probably cropped up due to a sudden power loss or due to naturally
occurring bit Rod as they were never configured to shut down nicely while on
backup power in the case of an outage and we've had quite a few of those over
the years now storage systems are usually designed to
be able to recover from such an event especially ZFS which is known for being
one of the most resilient ones out there after booting back up from a power loss
ZFS pools and most other raid or raid-like storage arrays should do
something called a scrub or a resync which in the case of ZFS means that
every block of data gets checked to ensure that there are no errors and if
there are any errors these errors are automatically fixed with the parity data
that is stored in the array on most Nas operating systems like true
Nas unread or any pre-built Nas this
process should just happen automatically and even if nothing goes wrong they
should also run a scheduled scrub every month or so but our servers were set up
by us a long time ago on Centos and
never updated so neither a scheduled nor
a power on recovery scrub was ever configured meaning the only time data
Integrity would have been checked on these arrays is when a block of data got
read this function should theoretically protect against bitrod but since we have
thousands of old videos of which a very
very small portion ever actually gets accessed the rest were essentially left
to slowly rot and power loss themselves
into an unrecoverable mess when we found
the drive issues we weren't even aware of all this yet and even though the five
drives weren't technically Dead We aired on the side of caution and started to
replace operation on all of them it was while we were rebuilding the array on
Delta 3 with the new disks that we started to uncover the absolute mess of
data errors ZFS has reported around
169 million errors at the time of
recording this and no it's not nice
in fact there are so many errors on Delta 3 that with two faulted drives in
both of the first v-devs there is not enough parity data to fix the errors and
this caused the array to offline itself to protect against further degradation
and unfortunately much further along in the process the same thing happened on
Delta 1. that means that both the original and
new petabyte projects old and new vault
have suffered non-recoverable data loss
so now what do we do in regards to the corrupted and lost
data honestly nothing I mean it's very likely that even with
169 million data errors we still have virtually all of the original bits in
the right places but as far as we know there's no way to just tell ZFS yo dog
ignore those errors you know pretend like they never happened to easy ZFS or
something instead then the plan is to build a new properly configured 1.2
petabyte server featuring seagate's shiny new 20 terabyte drives which we're
really excited about like these things are almost as shiny as our reflective
hard drive shirt LT store.com
and once that's complete we intend to move all of the data from the new Vault
cluster onto this new new vault
new new vault then we'll reset up new Vault ensure all
the drives are good and repeat the process to move old Vault data onto it
then we can reformat old Vault probably
upgrade it a bit and use it for new data maybe we'll rename it to new new Vault
get subscribed so you don't miss any of that we'll hopefully be building that
new server this week now if everything were set up properly
with regularly scheduled and post power loss scrubs this entire problem would
probably have never happened and if we had a backup of that data we would be
able to Simply restore from that but here's the thing
backing up over a petabyte of data is really expensive either we would need to
build a duplicate server array to backup to or we could back up to the cloud but
even using the economical option backblaze B2 it would cost us somewhere
between 5 and 10 000 US dollars per
month to store that kind of data now if it was mission critical then by all
means it should have been backed up in both of those ways but having all of our
archival footage from day one of the channel has always been a nice to have
and an excuse for us to explore really cool Tech that we otherwise wouldn't
have any reason to play with I mean it takes a little bit more effort and it
yields lower quality results but we have a backup of all of our old videos it's
called downloading them off of YouTube or Floatplane if we wanted a higher
quality copy so the good news is that our production monix server is running
great with proper backups configured and this isn't going to have any kind of
lasting effect on our business but I am still hopeful that if all goes
well with the recovery efforts we'll be able to get back the majority of the
data mostly error free but only time will tell a lot of time
because transferring all those petabytes of data off of hard drives to other hard
drives is going to take weeks or even months so let this be a lesson follow
Proper Storage practices have a backup and probably hire someone to take care
of your data if you don't have the time especially if you measure it in anything
other than tens of terabytes or you
might lose all of it but you won't lose our sponsor Lambda are you training deep
learning models for the next big breakthrough in artificial intelligence then you should know about Lambda the
Deep learning company founded by Machine learning Engineers Lambda builds GPU
workstations servers and Cloud infrastructure for creating deep
learning models they've helped all five of the big tech companies and 47 of the
top 50 research universities accelerate their machine learning workflows
lambda's easy to use configurators let you spec out exactly the hardware you
need from GPU laptops and workstations all the way up to custom server clusters
and all Lambda machines come pre-installed with Lambda stack keeping
your Linux machine learning environment up to date and out of dependency hell
and with Lambda Cloud you can spin up a virtual machine in minutes train models
with four NVIDIA a6000s at just a fraction of the cost cost of the big
cloud providers so go to lambdalabs.com Linus to configure your own workstation
or try out Lambda Cloud today if you like this video maybe check out the time
I almost lost all of our active projects
when the OG 1X server failed that was a
far more stressful situation I'm actually like
I'm actually pretty relaxed right now for someone with less much data on the
line yeah I'm I'm doing okay thanks for
asking I mean I'd prefer to get it back you
know