Now let's talk about Amazon EBS Snapshots.
So a really powerful feature of EBS
is the ability to take snapshots.
Like we talked about earlier, EBS volumes exist
in a single availability zone
and they are durable to the loss of a device
within that availability zone
but they are not durable to the loss
of that availability zone.
So if that availability zone is offline,
your data is unavailable.
If that availability zone is destroyed by natural disaster,
the data that is on that volume will also be destroyed.
And so volumes can be restored from snapshots, right?
So to mitigate that kind of thing
by taking regular snapshots,
we know that we have a backup of that volume somewhere
so that if the volume is accidentally deleted,
if the availability zone were to be destroyed,
then we still have a copy of that data somewhere
in the form of a snapshot.
When we take a snapshot of that volume,
the data is stored, the snapshot is stored, in S3.
So looking here, if we were to initiate a snapshot
of this volume then the data that comprises these snapshots
all gets stored over here within S3.
Now this is not to say that we have to create
and manage an S3 bucket.
AWS does that for us, right.
So the management of S3, the creation of buckets
and all of that, that's handled by AWS.
We just know that snapshots, according to AWS documentation,
we know that snapshots are stored within S3,
and we know that S3 gives us numerous copies
across numerous availability zones
so that S3 is durable to the loss
of an availability zone, right?
So if we're storing our data in the form of snapshots
if an availability zone is lost we will still have a copy
in the form of a snapshot.
Another great benefit of snapshots is the ability
to copy them to another region.
So if we taka snapshot of a volume,
that snapshot will be stored
in the same region as that volume.
We could then copy that snapshot
to any other region and by doing that,
now we have multiple snapshots,
now we have some geographical diversity.
We have backups of the data potentially thousands
of miles apart so that if an entire region were affected
by natural disaster, then we would still have a copy
of that data in another region.
We can also share those snapshots
so again it's common practice for organizations
to leverage multiple accounts.
And again you may have an account for admin purposes,
you may have an account for different environments
or accounts for different business units
and it's possible that you can take a snapshot
in one account and share that snapshot to other accounts.
Now the way that snapshots work
if we were to take a look at the mechanics
if we take a look here at this particular slide,
let's say here we have a block level volume, right,
and each one of these squares represents a block
on that volume.
If for let's say a fairly new volume we have a lot
of blocks but only some of them have data.
Right, we've only written data to a number of blocks here.
The first backup that we do will be a full backup
that includes all the data on that volume, right?
So the first backup includes all the data
that currently exists.
When we perform subsequent backups or snapshots
those are incremental, that's only recording deltas.
And so here perhaps we've changed some data, right,
in these blocks, and perhaps we've added some data
in some other blocks and so only the data that has changed
or been added will be included
in that subsequent snapshots.
And so a common question here is, well,
if you're only storing deltas,
what happens if you go back and delete like
an earlier snapshot.
And the answer to that is that
you may be taking regular snapshots
and each one only recording deltas.
If you go back and delete an earlier one,
or several or several dozen earlier ones, it doesn't matter,
any later snapshot will maintain a reference
to all of the data that it needs, right?
So just because you delete an old snapshot
doesn't mean that a later snapshot is now unusable, right?
Any snapshot that you take will include
all of the data necessary to restore that volume.
Another feature that we have access to
that we should keep in mind
is the data lifecycle manager,
and this was released fairly recently
in the latter part of 2018.
And for a long time people in my classes would ask me,
or clients of mine would also ask me,
"Hey, is there a way to automate snapshots?"
And I would say "Yeah, we can write a script to do that."
And this was a feature that we've been looking for
for a long time and now it's finally here,
the data lifecycle manager allows us
to automate these snapshots
so we can create a schedule here, right?
We can create a timer that says
every so often I want to automate these snapshots
and regularly take a snapshot of that volume.
So we as a customer, we define the backup
and retention schedules.
How often do we want those backups to be performed?
How long do we want those backups to be maintained?
And of course we can create those rules with tags.
We haven't really talked a whole lot about tags so far
but tags are a way of organizing our environment.
And tags are essentially arbitrary key-value pairs.
And so we could tag something with, say,
environment equals production,
or project equals whatever, cost center
and owner and so on.
And so we could use those life cycle rules
to say, well, every volume that's tagged
in a particular way should be, you know,
we should take a snapshot on a particular schedule.
So for those of us who have data
that is really important to us,
and we need to maintain a high degree
of durability in that data,
if we want to rest assured knowing
that we have not only copies of the data live
but also multiple copies of the data
in the form of backups
then we should take a look at EBS snapshots.