1
00:00:06,793 --> 00:00:09,876
- Now let's talk about EBS Snapshots.

2
00:00:10,762 --> 00:00:14,929
EBS Snapshots are a tool
that we can use to increase

3
00:00:15,828 --> 00:00:19,995
the durability of the data
stored on our EBS volumes.

4
00:00:20,876 --> 00:00:24,406
Now EBS volumes are in a
number of ways a really great

5
00:00:24,406 --> 00:00:27,862
tool to use within AWS just
because they're independent

6
00:00:27,862 --> 00:00:29,878
from the life of the EC2 Winstons,

7
00:00:29,878 --> 00:00:31,422
we have a lot of control over

8
00:00:31,422 --> 00:00:33,386
the performance of that volume,

9
00:00:33,386 --> 00:00:37,635
but they do exist in a
single availability zone.

10
00:00:37,635 --> 00:00:39,723
And while they are durable,

11
00:00:39,723 --> 00:00:41,422
they have some degree of resilience,

12
00:00:41,422 --> 00:00:42,896
they're resilient to the loss of

13
00:00:42,896 --> 00:00:44,810
a device within the cluster,

14
00:00:44,810 --> 00:00:49,081
they are not durable to the
loss of an availability zone.

15
00:00:49,081 --> 00:00:52,734
So going back to our fundamental
architectural question,

16
00:00:52,734 --> 00:00:55,989
what happens when this device fails?

17
00:00:55,989 --> 00:00:59,756
What happens when we lose
an availability zone?

18
00:00:59,756 --> 00:01:00,961
Even though it might be rare,

19
00:01:00,961 --> 00:01:03,131
it can still happen,
we have to plan for it,

20
00:01:03,131 --> 00:01:06,175
what happens when we lose
an availability zone?

21
00:01:06,175 --> 00:01:09,108
Then we should have a good answer to that,

22
00:01:09,108 --> 00:01:13,031
and the answer is well, we
have Snapshots of that volume

23
00:01:13,031 --> 00:01:17,198
that are stored in S3 which is
inherently highly available,

24
00:01:19,526 --> 00:01:23,756
S3 is durable to the
loss of up to two AZs,

25
00:01:23,756 --> 00:01:26,024
so that means our data is still there,

26
00:01:26,024 --> 00:01:29,044
and we can recreate that volume from

27
00:01:29,044 --> 00:01:32,289
that Snapshot in another
availability zone.

28
00:01:32,289 --> 00:01:34,537
So when we take a Snapshot,

29
00:01:34,537 --> 00:01:37,310
let's say we take a
Snapshot of this volume,

30
00:01:37,310 --> 00:01:41,060
that Snapshot will be
stored over here in S3.

31
00:01:43,048 --> 00:01:46,809
Now I like to think of that being stored

32
00:01:46,809 --> 00:01:50,083
in some kind of what I call an admin zone,

33
00:01:50,083 --> 00:01:54,410
and I say that because we
don't have direct access

34
00:01:54,410 --> 00:01:57,645
to the raw storage of the Snapshot,

35
00:01:57,645 --> 00:01:59,984
but we do know it's stored in S3.

36
00:01:59,984 --> 00:02:02,506
What we have access to
in the Amazon console,

37
00:02:02,506 --> 00:02:06,213
we will see Snapshots as a
resource that we have access to,

38
00:02:06,213 --> 00:02:10,380
we just can't get to the
underlying raw storage in S3.

39
00:02:11,450 --> 00:02:14,750
AWS makes it really easy
with the command line tools,

40
00:02:14,750 --> 00:02:17,304
with the SDKs, even the console,

41
00:02:17,304 --> 00:02:21,194
to copy that Snapshot to another region.

42
00:02:21,194 --> 00:02:24,493
So for disaster recovery purposes,

43
00:02:24,493 --> 00:02:27,862
we might want to create Snapshots here

44
00:02:27,862 --> 00:02:30,611
and then perhaps our business policy

45
00:02:30,611 --> 00:02:33,133
or some type of regulatory policy says

46
00:02:33,133 --> 00:02:37,784
that we need geographical
diversity in our data,

47
00:02:37,784 --> 00:02:42,628
we can use this copy command
to copy that Snapshot

48
00:02:42,628 --> 00:02:46,970
to another region and perhaps
we have our initial data

49
00:02:46,970 --> 00:02:49,814
stored on the West Coast and we copy that

50
00:02:49,814 --> 00:02:52,674
to a region on the East
Coast and now we have

51
00:02:52,674 --> 00:02:56,833
several thousand miles
between our copies of data,

52
00:02:56,833 --> 00:02:59,195
and that gives us our
geographical diversity.

53
00:02:59,195 --> 00:03:02,945
We can also share
Snapshots between accounts.

54
00:03:03,820 --> 00:03:07,582
If we're doing something with
data in the production account

55
00:03:07,582 --> 00:03:11,376
and we wanna get that
back over to some kind of

56
00:03:11,376 --> 00:03:14,383
development or test
environment in another account,

57
00:03:14,383 --> 00:03:15,914
we can do that as well,

58
00:03:15,914 --> 00:03:19,710
we can share that Snapshot
to another account.

59
00:03:19,710 --> 00:03:23,418
The first time we take a
Snapshot of an EBS volume,

60
00:03:23,418 --> 00:03:27,585
we are going to take all of
the data that's on that volume

61
00:03:28,729 --> 00:03:32,127
and that will become our Snapshot.

62
00:03:32,127 --> 00:03:36,294
From there on, subsequent
Snapshots will be incremental,

63
00:03:37,528 --> 00:03:41,920
that is, only new data
or data that has changed,

64
00:03:41,920 --> 00:03:45,920
you can see here that
these blocks have changed,

65
00:03:47,291 --> 00:03:49,168
and then of course we have
another couple of blocks

66
00:03:49,168 --> 00:03:52,877
that are new, new data,
so only those blocks

67
00:03:52,877 --> 00:03:55,956
that have changed or become new data

68
00:03:55,956 --> 00:03:59,539
will be a part of that
subsequent Snapshot.

69
00:04:00,967 --> 00:04:05,043
So again, EBS Snapshots
are the way to increase

70
00:04:05,043 --> 00:04:08,787
the durability of your data
to get geographical diversity

71
00:04:08,787 --> 00:04:11,790
of your data and a way
to recreate your volumes

72
00:04:11,790 --> 00:04:13,903
in the case that they're lost or

73
00:04:13,903 --> 00:04:16,380
accidentally deleted or whatever.

74
00:04:16,380 --> 00:04:20,547
So that's EBS Snapshots
within Amazon Web Services.