Welcome to our new series of articles, and meet DevSecOps MythBuster. This thick-skinned and insightful hunter will investigate and overthrow the most common myths about DevOps backup. <\/p>\n\n\n\n\n\n\n\n
Why do we need such a hero?<\/p>\n\n\n\n
\u274c I use Git so I don\u2019t need backup We cannot count how many times we have heard similar statements from our prospects. How many absurd, repeated misconceptions about data protection, SaaS, and Cloud have we had to debunk. How many we had to educate that what they thought backup was, was no backup at all. <\/p>\n\n\n\n But yes, eventually, they became our customers. <\/p>\n\n\n\n Let\u2019s start. DevOps Mythbuster can\u2019t wait to debunk some of the most popular myths and challenge common beliefs.<\/p>\n\n\n\n MYTH #1 Ohhhh\u2026 this is our favorite one! <\/p>\n\n\n\n Git, a version control system, and its hosting services like GitHub, GitLab, or Bitbucket seem to be self-healing bulletproof tools – resistant to any human error, ransomware attack, or outage. <\/p>\n\n\n\n Since Git versions your code and files, recording the complete history of changes you make, after accidental deletion it will be able to recover them, right? But what if you do not regularly push your commits? How long will it take you to restore and merge all data?<\/p>\n\n\n\n Or otherwise – what if someone (intentionally or not) wipes out data, deletes branches, or overwrites HEAD and pushes those changes? <\/p>\n\n\n\n Finally, what will you do if GitHub, GitLab, or Bitbucket go down for two weeks? Before you say it\u2019s impossible – It happened to Atlassian\u2019s Jira users one year ago<\/a>! Will you be able to restore your previous version and keep on working?<\/p>\n\n\n\n Or what if by any accident one of those vendors wipe out your account data? Let us pull the ace up our sleeve again – such a major in VCS history backup failure happened to GitLab<\/a>. So if GitLab wasn’t able to restore their data, are you sure you are?<\/p>\n\n\n\n Worth remembering! Version control systems are great at keeping track of code. Eventually, they were designed to do so. But the features of a good VCS are entirely different from the features which make a good DevOps backup<\/a> software.<\/p>\n\n\n\n Just to name a few (this is no time to brag): backup automation, easy setup, full data coverage (repositories and METADATA!), multi-storage compatibility, and data replication between storages (to meet the 3-2-1 backup rule), data encryption, central management. Add to this list Disaster Recovery<\/a> technologies ready for any scenario (possibility to restore all data to the local machine, same\/new account, or even different vendor to migrate data between VCSs) and granular restore of only chosen items – powerful for daily operations. <\/p>\n\n\n\n And if that still doesn’t convince you, let’s use one of the fundamental reasons in business – finance, time, and work. Even if you think you can restore your data directly from git and revert them to the previous state (from any point in time) – try to calculate the cost. How much manpower and time will you spend on this? What is the alternative cost of their time? How much data can you afford to lose, and how much did it cost to write the lost piece of code?<\/p>\n\n\n\n This is the price it costs to believe in this one of the most repeated DevOps backup myths. Don\u2019t want to pay for it? We have got your back(up)!<\/p>\n\n\n\n Are you a visual learner? Don’t miss our video where we have broken this myth out: <\/p>\n\n\n\n
<\/em>\u274c GitHub\/Atlassian\/GitLab\/(put any SaaS here) handles backup
<\/em>\u274c Nothing fails in the cloud
<\/em>\u274c I can build a script<\/em>\ud83d\udd25<\/p>\n\n\n\n
I use GitHub\/GitLab\/Bitbucket so I don\u2019t need backup<\/em><\/p>\n\n\n\n