Maintaining data integrity and guaranteeing business continuity is of utmost importance for any organization. However, in today's world, those systems have grown in complexity and cost, while the business demands IT agility and lower costs. In this talk, we will explore how organizations should approach backup and disaster recovery, and how these two aspects can be implemented in the cloud to improve efficiency and flexibility. The talk starts with general concepts, and then dives into technical details, culminating in real customer examples that showcase some tips and tricks and the benefits of a cloud-based approach.

1. Parmigiano, a Monastery,
Love and Faith
Technical lessons on how to do
backup and disaster recovery in the cloud
Simone Brunozzi
Senior Technology Evangelist, Amazon Web Services
@simon

2. "The mind is not a vessel to be filled,
but a fire to be ignited."
- Plutarch

3. Agenda
I. Prologue The story of Monte Cassino
II. Lessons Backup
III. Customer Story Shaw Media
IV. Earthquake What happened to my Parmigiano?
V. Lessons Disaster Recovery
VI. Conclusions ... And a little surprise!

4. Part I
Prologue

5. Abbey of
Monte
Cassino

6. [ Why is Monte Cassino important? ]

7. [ The Treasure of Monte Cassino ]

8. 800 papal documents
20,500 volumes in the Old Library Titian, one of the
60,000 in the New Library most influential
painters ever
200 manuscripts on parchment
100,000 prints and paintings (including 11 Titians)
500 incunabula
Gutenberg’s Bible
was printed in 1455
C.E.
A book printed
before 1501 C.E.
[ The Treasure of Monte Cassino ]
x

9. High Backup Disaster
availability storage recovery
[ Business continuity continuum ]

10. High Availability :
Keeping services alive.
[ Business continuity continuum ]

11. High Availability :
Keeping services alive.
Backing up :
Process of copying and archiving of data so it may be used to
restore the original after a data loss event.
[ Business continuity continuum ]

12. High Availability :
Keeping services alive.
Backing up :
Process of copying and archiving of data so it may be used to
restore the original after a data loss event.
Disaster recovery :
Recovery of technology infrastructure critical to an
organization after a natural or human-induced disaster.
[ Business continuity continuum ]

13. Monastery :
Brilliant, scalable, low-cost, highly durable backup system
Origin of Universities (Charlemagne, 814 C.E.)
The Empire Edict: Free
needs educated education in
people cathedrals and
Let’s ask the monasteries
Church!
Lots of books
(and backups)
[ Origin of Backup ]

14. Monastery :
Barbarians,
Brilliant, scalable, low-cost, highly durable backup system.
pestilences, fires,
Origin of Universities (Charlemagne, 814 a.C.)
invasions, wars,
famines, revolts, etc.
Indoctrination :
One of the first critical function within an organization
(Catholic Church) that needed continuation after any natural or
human-induced disaster.
It needed backup of books (Bibles, etc.) in order to function.
[ Origin ]

15. [ Why is Monte Cassino important? ]

16. [ World War II ]

17. Dec 1942: Many “treasures”
are transported from Rome
and other places to Monte
Cassino, for safety
[ The Treasure of Monte Cassino ]

18. Intercepted German message:
“Ist der Abt noch im Kloster?”
“Ja.”
It means
“Military
Division” It also means
(abbreviated) “Abbot”
(abbreviated)
[ Lost in translation ]

19. [ Abbey of Monte Cassino ]

20. Feb 1944: Schlegel and Becker
(Panzer-Division Hermann
Göring) had the treasures
transferred to the Vatican
[ The Treasure of Monte Cassino ]
x

21. [ Escape from Monte Cassino ]

22. Lt. Col. Julius
Schlegel
(an Austrian Roman
Catholic)
Capt. Maximilian
Becker
(a Protestant
surgeon)
[ Escape from Monte Cassino ]

23. “Biggest bombing against a
single target of all time”

24. [ Monte Cassino after bombing (1944) ]

25. [ Restoration in 1954 ]

26. [ The Abbey of Monte Cassino today ]

27. End of Prologue

28. Part II
Lessons from Monte Cassino

29. 1. My backup should be accessible
a.k.a. the pain of
physical data
transfer

30. 1. My backup should be accessible
AWS Direct Connect API
AWS Storage Gateway
Customer owns the data
Redundancy
AWS
AWS Import/Export

31. GW-stored volumes
[ AWS Storage Gateway ]

32. z

33. GW-Cached volumes
GW-stored volumes
“Cold”
“Cool” storage
w

34. Public / AWS Direct Connect
VPN
AWS Import/Export
z

35. 2. My backup should be able to scale

36. 2. My backup should be able to scale
• “Infinite” scale with Amazon S3 and Amazon Glacier
• Scale to multiple regions
• Seamless
• No need to provision
• Cost tiers (cheaper at scale)
[ Lessons from Monte Cassino ]

37. Regions (8) GovCloud Regions (1)
[ Global AWS Infrastructure ]
(as of Nov 27th, 2012)

38. Availability Zones (23)
[ Global AWS Infrastructure ]
(as of Nov 27th, 2012)

39. Seattle South Bend New York (2) London Amsterdam (2)
Newark Dublin Stockholm
Palo Alto
Tokyo
San Jose
Paris Frankfurt (2)
Ashburn (2) Milan
Los Angeles (2) Jacksonville Madrid Osaka
Dallas (2) Hong Kong
St.Louis
Miami Singapore (2) Sydney
São Paulo
Edge Locations (38)
[ Global AWS Infrastructure ]
(as of Nov 27th, 2012)

40. 3. My backup should be safe

41. 3. My backup should be safe
• SSL Endpoints (Amazon S3 and Amazon Glacier)
• Signed API calls
• Store encrypted files
• Server-side encryption
• Durability: multiple copies across different data centers
• Local/cloud with AWS Storage Gateway
[ Lessons from Monte Cassino ]

42. 3. My backup should be safe

43. 4. My backup should work with a DR policy
(I don’t want to wait 10 years… )

44. 4. My backup should work with a DR policy
• Easy to integrate within AWS or Hybrid
• AWS Storage Gateway: Run services on Amazon EC2 (DR)
• Clear costs
• Reduced costs
• I decide redundancy/availability in relation to costs
[ Lessons from Monte Cassino ]

46. 5. Someone should care about it
• Clear ownership
• Permissions with IAM: Users, groups  roles
• Logs
• AWS support
[ Lessons from Monte Cassino ]

47. 1. My backup should be accessible
2. My backup should be able to scale
3. My backup should be safe
4. My backup should work with a DR policy
5. Someone should care about it
[ Lessons from Monte Cassino ]

48. Part III
A customer story

49. Augusto Rosa
Manager, Server Operations – Shaw Media
augusto.rosa @ shawmedia.ca

50. [ Shaw Media ]
50

51. [ Who we are ]
• Shaw Media: Division of Shaw Communications Inc.
• It reaches almost 100% of Canadians; 18 specialty channels
• Global national newscast: 1+ million viewers every weekday
• Access to full episodes: 20 websites, 4 video-on-demand
• It engages with 25+ million Canadians per week

52. [ Before AWS ]
• Data centers in Winnipeg and Toronto
• Challenge to manage, frequent power outages, downtime
• Expensive hosting fees inherited from parent company
• Technology was old and in disarray (total revamp needed)

53. [ Mission Impossible? ]

54. [ Mission ]
• Implement a new CMS
• Empower the editorial team
• Business objectives
• Time frame of 9 months
• Be agile and cost effective

55. AWS

56. Amazon EC2 Amazon SQS
Amazon EMR Amazon SNS
Auto Scaling Amazon SES
Elastic Load Balancing
AWS Marketplace
Amazon CloudFront Amazon FPS
Amazon RDS Amazon DevPay
Amazon DynamoDB Amazon Mechanical Turk
Amazon SimpleDB
Amazon ElastiCache Amazon Route 53
Amazon VPC
AWS Identity and Access Management AWS Direct Connect
Amazon CloudWatch
AWS Elastic Beanstalk Amazon S3
AWS CloudFormation Amazon Glacier
Amazon EBS
Amazon CloudSearch AWS Import/Export
Amazon SWF AWS Storage Gateway
Alexa WIS and Alexa Top Sites AWS Support

57. [ Phase One ]
• Fast deployment of servers, network rules, load balancers
• First site under new CMS: Live in 4 weeks from scratch
• Full migration of 29 sites from a physical DC in 9 months

58. [ Phase Two ]
• Full migration of 6 other websites and web services
• From 2nd physical DC into AWS in 2 months
• Migration: Windows ‘03/SQL ‘05  Windows ‘08/SQL ’08
• Creating new web farms takes 1 to 5 days (versus months)
• Takes longer to procure licenses than the infrastructure
• Ability to scale and automate

59. [ Benefits of Using AWS ]
• Increased uptime from 98.8% to 99.99%
• Scale to success, quicker response to business needs
• 1+ M $ saved in capital and operational cost
• No physical investment, smaller teams
• Allowed using service management third-party companies
• Easy backup on AWS  3 years retention (tax credits)

60. [ AWS Architecture ]

61. [ Some Numbers ]
• 50+ EC2 instances (various sizes)
• 25+ TB traffic/month
• 40M+ Route 53 queries
• 10+ TB backup on Amazon S3
... And growing!

62. [ Lessons Learned ]
• Architecting for AWS in mind from start
• Use all Availability Zones in area you choose to host;
divide across all
• Plan for failures: Be crazy about it (things fail)
• Backup backup backup
• Monthly AMI
• Windows/SQL Server workarounds (failover cluster, AD, etc.)
• Engage with AWS Solutions Architects early

63. [ Disaster Recovery ]
• Learn from outages all the time
• Implement changes to prevent failures at cloud level
• Document how you recover from failures
• Single component may fail; architecture shouldn’t

64. [ Backup ]
• Daily snapshots of all volumes automatically
• VIP volumes: snapshots every 4 hours
• Keep the last 10 snapshots
• Dell Replay: It backs up file system files every 1 hour
• Volumes replicated to Amazon S3 (Oregon) every 2 hours
• SQL Server backup every 30 minutes
• SQL Server backup volumes moved to Amazon S3 every
2 hours

65. [ Future ]
• Move from public cloud to VPC
• Auto Scaling on Amazon EC2
• Amazon S3 as image repository for all sites
• Second cloud vendor as DR (instead of in-house)
• Amazon ElastiCache for central caching for ASP.net apps

66. Augusto Rosa
Manager, Server Operations – Shaw Media
augusto.rosa @ shawmedia.ca

67. Part IV
The 2012 Emilia Earthquake

68. [ May 20th, 2012: Earthquake in Italy ]

70. [ Parmigiano warehouse (0.5B € damage) ]

71. [ “Let’s do something NOW” ]

72. [ Buy 1 Kg of Parmigiano for 1 Euro ]

73. [ Everybody helped ]
73

74. Part V
Lessons from an Earthquake

75. 1. You NEED a DR in place!
2. Testing your DR
3. Reducing costs
4. You can have different DR solutions
[ Lessons from an Earthquake ]

76. 1. You NEED a DR in place!

77. DR with High Availability

78. App DR with Standby

79. Business Impact Analysis (RTO, RPO)

80. Business Impact Analysis (RTO, RPO)
• RTO (Recovery Time Objective):
1) Time for trying to fix the problem
2) The recovery itself
3) Testing
4) Tell users
• RPO (Recovery Point Objective): how much data I can lose
[ Lessons from an Earthquake ]

81. Different Types of DR Architecture
1) Backup and Restore
2) “Pilot light” for quick recovery into AWS (cold standby)
3) Warm standby solution on AWS
4) Multi-site hybrid solution (AWS + on premises)
[ Lessons from an Earthquake ]

82. Cost
Performance Durability
($/GB/month)
Amazon S3 0.125  
Amazon
0.01  
Glacier
AWS Storage 0.125
 
Gateway (+ 125/GW)
Amazon EBS 0.10  
Amazon EBS
0.125  
(PIOPS)

83. 2. Testing your DR
83

84. 2. Testing your DR
• Dev/test in the cloud is super easy
• Spin up capacity only for the test
• Regularly test your DR
• Cost is minimal
• What about data transfer speed?
[ Lessons from an Earthquake ]

85. s3cmd ls --recursive
s3://datasets.elasticmapreduce/ngrams/b
ooks/ | awk '{print $4;
sub(/s3://datasets.elasticmapreduce/,
"/array", $4); print $4}' | parallel -
j0 -N2 --progress /usr/bin/s3cmd --no-
progress get {1} {2}
Special thanks to Craig Carl, AWS Solutions Architect

86. s3cmd ls --recursive
s3://datasets.elasticmapreduce/ngrams/b
ooks/ | awk '{print $4;
sub(/s3://datasets.elasticmapreduce/,
"/array", $4); print $4}' | parallel -
j0 -N2 --progress /usr/bin/s3cmd --no-
progress get {1} {2}
Lists every object
in the bucket

87. s3cmd ls --recursive
s3://datasets.elasticmapreduce/ngrams/b
ooks/ | awk '{print $4;
sub(/s3://datasets.elasticmapreduce/,
"/array", $4); print $4}' | parallel -
j0 -N2 --progress /usr/bin/s3cmd --no-
progress get {1} {2}
Gets the path to the Amazon
S3 object and the local
destination path

88. s3cmd ls --recursive
s3://datasets.elasticmapreduce/ngrams/b
ooks/ | awk '{print $4;
sub(/s3://datasets.elasticmapreduce/,
"/array", $4); print $4}' | parallel -
j0 -N2 --progress /usr/bin/s3cmd --no-
progress get {1} {2}
Runs parallel with as many
threads as possible, '-N2' tells
parallel there were two
arguments on stdin and
assigns them to {1} and {2}

89. s3cmd ls --recursive
s3://datasets.elasticmapreduce/ngrams/b
ooks/ | awk '{print $4;
sub(/s3://datasets.elasticmapreduce/,
"/array", $4); print $4}' | parallel -
j0 -N2 --progress /usr/bin/s3cmd --no-
progress get {1} {2}
It’s the command that GNU
Parallel will run, '{1}' is
substituted with the Amazon
S3 object path, '{2}' is
substituted with the local
destination path

90. s3cmd ls --recursive
s3://datasets.elasticmapreduce/ngrams/b
ooks/ | awk '{print $4;
sub(/s3://datasets.elasticmapreduce/,
"/array", $4); print $4}' | parallel -
j0 -N2 --progress /usr/bin/s3cmd --no-
progress get {1} {2}
Copying 2.4 TB
down from 48 hours
to 9 hours (5x faster)

91. 3. Reducing costs

92. 3. Reducing costs
1) AWS cost reduction (e.g., S3 cost reduction on Nov 28)
2) Reduced redundancy (Amazon S3)
3) Retention policy
4) Hot/warm/cool/cold backup
5) Reserved capacity/tiers
[ Lessons from an Earthquake ]

93. Standard Reduced
Amazon S3
$/GB/Month $/GB/Month
0–1 TB 0.125 0.093
1–50 TB 0.110 0.083
50–500 TB 0.95 0.073
500–1,000 TB 0.90 0.063
1–5 PB 0.80 0.053
5+ PB 0.55 0.037

94. 4. You can have different DR solutions
94

95. 4. You can have different DR solutions
• Easy to integrate existing vendors with DR on AWS
• Approach: One vendor/hybrid/multiple vendors
• One region/multi-regions (if you need geodiversity)
[ Lessons from an Earthquake ]

96. 1. You NEED a DR in place!
2. Testing your DR
3. Reducing costs
4. You can have different DR solutions
[ Lessons from an Earthquake ]

97. Part VI
Conclusions

99. Action items
Backups
Disaster Recovery
Cost
Agility Control
savings
x

100. Parmigiano, a Monastery,
Love and Faith
Technical lessons on how to do
Backup and Disaster Recovery in the Cloud
Simone Brunozzi
Senior Technology Evangelist, Amazon Web Services
@simon