back to article Oh snap: AWS has only gone and brought out its own Backup

Amazon has rolled out its own backup service for AWS apps and data, a move that will inevitably hit independent suppliers of backup for the cloud computing service right in the wallet. AWS Backup protects storage volumes, databases, and file systems across Amazon's DynamoDB, Elastic Block Store (EBS), Elastic File System ( …

  1. WibbleMe

    Useful but the whole concept of an office site back up is if its somewhere else in the world not in the same data centre.

    1. Gordon 10 Silver badge
      Flame

      Precisely. Where is the backup stored and how independent is every component from the main AWS infrastructure?

      For example during the Spectre patches we had about 5% of our VM's b0rked resulting in data corruption. What happens if those same patches b0rked the backups?

      1. Tom Chiverton 1

        Stored on S3. Globally redundant single name space. Seems fine.

        1. Mr.Nobody

          But S3 is only local to that region, no?

          Its not like you could then replicate these backups to another region?

          I guess we'll find out when the details are flushed out.

          1. Gunboat Diplomat

            Re: But S3 is only local to that region, no?

            You can set up cross region replication in s3 to a bucket in another region.

            1. Mr.Nobody

              Re: But S3 is only local to that region, no?

              Yes, but will one be able to use to restore from their backup service in the other region - the application can't read that replicated S3 data and restore from it, its not much help.

              1. Anonymous Coward
                Anonymous Coward

                Re: But S3 is only local to that region, no?

                Yes of course, you can access replicated objects in a different region bucket using its globally unique url for S3 objects

        2. json

          A more expensive alternative is EFS, its replicated across the region so you're better off with that for backups.

          1. Olly_SW

            Both EFS and S3-STD are replicated across a minimum of 3 or more AZ's in a AWS Region, so you would have to lose all 3 distributed data centres to lose data..hence the durability of S3 objects is 99.999999999%

        3. Anonymous Coward
          Anonymous Coward

          Globally unique name space..Regionally resilient objects i.e S3 Objects are stored in a minimum of 3 AZ's across a region

    2. FuzzyWuzzys Silver badge

      Off the mark

      That shows a lack of AWS understanding. AWS doesn't have data centres in the traditional sense, given how they currently distribute data over multiple locations it's very, very unlikely they will have single point of storage of something as critical as backups.

      1. K Silver badge

        Re: Off the mark

        @FuzzyWuzzys That is BS, AWS use data centres in the traditional senses, also they often collocate their services in 3rd party data centres (specifically there edge and POP services) - they may have some epic private Inter-connectivity between, but does not make them "special".

        Do you think they use fairy dust?

  2. Locky Silver badge

    All fine and dandy

    Until you need to move cloud providers. AWS will offer you all your data back, but I bet it's going to cost you

    1. K Silver badge

      Re: All fine and dandy

      Agreed - but from my past experience of working for companies who adopt "cloud-first", they stick with a single provider, main reason for this, is they're so integrated into a provider, moving would be too difficult - Its just another form of vendor lock-in.

      For example, my current employer uses AWS for our customer-facing systems, they are designed to scale at peak, in addition all our internal pipeline tools are built to work with AWS API's - migrating these to Azure, would take a colossal effort

      On a personal, even after working for these companies... I still say, unless you are a start-up or have a need to constantly scale up and down, then just co-locate a few racks, its a hell of a lot cheaper!

      1. Mr.Nobody

        Re: All fine and dandy

        Hell of a lot cheaper. I had heard a good guide line is that once you hit $5K a month in cloud costs, doing it in colo is cheaper. I can attest to that.

        We have colocation sites with 8 racks and using loads of power, and the service is less than $10K a month. None of these sites has had an outage in the 9 years I have been around.

        Storage arrays are way cheaper than they used to be, and flash.

        Servers are cheap, especially if you buy used ones.

        Hypervisors are a commodity these days.

        Internet bandwidth is cheap - certainly when you don't pay by the bit sent.

        Lots of people are leaving the cloud as the notion of it being cheaper is just laughable.

        1. Anonymous Coward
          Anonymous Coward

          Re: All fine and dandy

          Yes, those things are cheap. The meatbags to manage and maintain are not though. Set up your own Hadoop cluster and you'll see why cloud is popular. It frees the staff to genuinely innovate rather than be bogged down with maintenance. Management are generally not happy with the IT department getting bigger so you usually have to choose between managing and innovating. Sometimes you can have both, but not often.

          1. Mr.Nobody

            Re: All fine and dandy

            Yes, I get this sentiment - it does make sense when you imagine it, but there is still maintenance and operational work to be done with a cloud environment, albeit different maintenance.

            And while the meatbags are expensive, so are the meatbags that one would need to hire to have an effective cloud deployment. Letting developers with 20 years of coding experience and zero experience working in operations or systems leads to badly designed cloud deployments.

            Now the push is all about Hybrid deployments, so you still need the meatbags that run all the on premises gear as well as the meatbags that are dealing with the cloud deployments.

            As to innovation - if a company has business needs that require innovation - problems that need solving, cloud is rarely the answer to the problem. Nothing that can be done by any of these cloud providers changes business needs all that drastically. The only case I can see it being a game changer is the ability to grow exponentially on demand to deal with slashdot effect as we used to call it.

            Any other innovations can be done on premise just as well as in the cloud.

        2. Tomato Krill

          Re: All fine and dandy

          Nobody that isnt a cowboy sells the cloud as cheaper. That's not it's selling point

          1. Anonymous Coward
            Anonymous Coward

            Re: All fine and dandy

            I've seen plenty of cowboys attempt to sell that it was cheaper. And a cowboy director who believed this. Then a consultant came in after a few other cowboy consultants that tried to go along with the director that it was cheaper, just because they wanted to milk the company for money. Then this new consultant finally got them to see "It's not cheaper, it's actually a hell of a lot more expensive". Then she left shortly after :(

            This is the problem. To many cowboy consultants and to many directors willing to believe them.

            1. doublelayer

              Re: All fine and dandy

              But the major benefit of cloud is that it can be cheaper, conditions apply. The cloud providers sell economies of scale where your usage can be balanced against everyone else's usage to reduce the total amount spent on computing so you only pay for what you're using, as well as your risk of hardware problems which again reduces your cost. Otherwise, cloud doesn't tend to offer much more than you could do with your own hardware. There is a minor benefit in having geographically-distributed systems for faster access by people in distant locations, but this is rarely an issue of paramount importance. If cloud isn't cheaper, the only benefit that is distinctly relatable to cloud is scalability, but again, conditions apply. So many people either jump on the cloud bandwagon or refuse to use any cloud-related product whatsoever without actually looking at whether it is useful in the situation.

  3. hellwig Silver badge

    Cue the EU...

    So, doesn't offering your own competing service up front violate antistrust laws? If Microsoft isn't allowed to "prefer" IE/Edge over other web browsers, Amazon can't "prefer" their own backup service over competitors, can they?

    Or does the EU only care about Microsoft and Google?

    1. Paul Hargreaves

      Re: Get burned?

      Is AWS a monopoly? Are there viable alternatives that have market presence? If so, it won't be an issue.

      1. phuzz Silver badge

        Re: Get burned?

        From this article from last month/year:

        Microsoft - $21.2B

        AWS - $20.4B

        IBM - $10.3B

        Oracle - $6.08

        Google - $4B

        Alibaba - $2.2B

        So no, not much of a monopoly when they're in second place (just) and there's at least three other providers in with a shout of them.

        1. hellwig Silver badge

          Re: Get burned?

          So anti-competitive behavior is fine as long as you aren't too successful? I know that's Apple's business model (find a cool app, put that feature in the OS, then ban the app).

          What is the percentage threshold that has to be reached? At what point is it unfair for Amazon to offer their backup service on the front page as you sign up for AWS, when you have to search the internet to find competitors for the BACKUP service (obviously there are AWS competitors)? And of course, if you use Google to search, and Google has the AUDACITY to offer their own product, they will be the ones to get fined. It's ridiculous.

          1. Jack of Shadows Silver badge

            Re: Get burned?

            It's ridiculous.

            That's a pretty good descriptor for competition theory in economics. And when you compare what they say in the Economics department against what they say over at the Business School, well ... being on LSD and 'shrooms at the same time about describes that.

          2. phuzz Silver badge

            Re: Get burned?

            "What is the percentage threshold that has to be reached?"

            Turns out, in the UK it's 25% of the market, so both Amazon and Microsoft would be considered monopolies (in the cloud market) in the UK. Mea culpa.

        2. katrinab Silver badge

          Re: Get burned?

          Then there's the likes of Rackspace, privately owned so not required to publish such detailed accounts, but it looks like about $1bn, OVH is about €0.4bn, and plenty of other smaller players.

  4. sabroni Silver badge

    AWS backups are based on snapshots

    What does that mean exactly? On SqlServer a snapshot is a quick file system level "backup" with restrictions on restore (you can have multiple snapshots but can only restore one and must delete the others first). This product isn't like that is it? If not, what does this usage of snapshot mean?

    1. #define INFINITY -1 Bronze badge

      Re: AWS backups are based on snapshots

      My mucking with KVM some time back suggests to me that it is a point-in-time backup. Start the machine and it sees a time jump from backup-time to now.

    2. Lusty Silver badge

      Re: AWS backups are based on snapshots

      You don't have to delete other snaps first VSS allows mounting of any snapshot so you can copy the data out. You're thinking about rollback which is different to restoring data.

  5. TRT Silver badge

    Eggs & baskets comes to mind...

    Of course some of the other basket providers are, I suspect, merely pseudo basket providers and are simply rebadging the same basket that your eggs are in.

  6. stribble

    It sends a message

    And that message is: if you put data in the cloud, you still need to back it up.

    So many people forget that, which is why I think this news from AWS is just covering their backs. Organisations wanting to consolidate to one backup system across a hybrid cloud estate will ignore this product, and I don't think it will bother Amazon for one second.

  7. TechDrone
    Meh

    Only backs up up 1 database - theirs

    So not much use by itself if you want "proper" backup of any other database. Unless you're happy fart-arsing around with two-stage backup and restore via file system dump and manually getting the transaction logs back and loading by hand.

  8. hmmm

    All your eggs in one basket

    We back up because:

    1. What do we do if Amazon ever flick a switch and delete or block our account?

    2. Rogue Admin threat. The Admins with access to Amazon don't have access to our backup provider (Security hold the Admin credentials).

    Backing up internally doesn't make much sense to me, but then I am the paranoid type.

    1. doublelayer

      Re: All your eggs in one basket

      Backing up internally can be useful in a few situations, for example if you messed up your VM or database and need it restored to the way it was before you did that. Mostly, that's an insurance policy against user failure, analogous to internal backups taken off on-prem servers and stored locally. For the typical case of backups, that is restoring data after something has destroyed your current system, it is less useful. Normal cloud activity is supposed to be insulated from things like disk failures by the cloud provider, so, if you are restoring backups for a small scale hardware problem, your provider probably has a major problem and you shouldn't be using them. Meanwhile, if something happens that is large enough that it takes out a datacenter, your backups stored there will be just as gone as the services you ran there. Maybe this backup solution will allow you to download the backup data and store it on a system of your choice, but I doubt it.

      1. Anonymous Coward
        Anonymous Coward

        Re: All your eggs in one basket

        Backups are stored in S3 which is spanned across a minimum of 3 AZ's in a region automatically, so you would have to lose 3 data centres separated by many miles before you would lose any data

        1. Alan_Peery

          Re: All your eggs in one basket

          Which does not address the rogue admin threat, the leaked credential threat, or the billing screwup threat.

    2. katrinab Silver badge

      Re: All your eggs in one basket

      You mess up an upgrade and want to roll back. Then an internal backup would probably be quicker.

      A user accidentally deletes a file and you need to restore it.

      Those are the most common reasons for restoring a backup.

  9. WYSIWYG650

    AWS = Hotel California

    AWS = The Hotel California, because you can check out but you can never leave! Or a roach motel comes to mind. Cloud savvy end users are realizing the value of avoiding cloud vendor lock in!

  10. J. Cook Silver badge

    Snapshots...

    I'm assuming (that horrible, horrible word) that they are similar to 'block level' snapshots, similar to what other virtualization, backup, and storage vendors use. (VMware uses change block tracking and delta disks, Nimble and (IIRC) Veeam use change block tracking as well. If I recall how SQL server snapshots work correctly , it writes the old data that got changed to a seperate database file when a row is updated or added to a table.

    I've not actually looked at AWS for anything, it's something of an anathema here at [RedactedCo]. Azure, if anything would probably leverage whatever methodology Hyper-V uses for snapshotting it's VMs, although I could be waaaaay off.

    I find it ironic that they are charging for restores.

  11. Dwarf Silver badge

    Our backup supplier sources acknowledged AWS convenience would be a strong factor but warned that customers should beware of lock-in, particularly in the emerging multi-cloud world.

    Because our lock in is better than their lock in.

  12. Michael Hoffmann
    Unhappy

    As usual...

    The one thing that really gets my knickers in a twist:

    Big announcement followed by "not yet available in your region".

  13. Anonymous Coward
    Anonymous Coward

    Not so secret secret

    ... amazon instance prices are competitively priced, but storage price doesnt seem to budge much at all. My AWS bill has a big chunk of charge for storage, started out as a volume which we backup using daily "snapshot".. and recently moved to EFS so we dont even have to do that snapshot ourselves. EFS is per GB more expensive than a EBS + Snapshot combined.. but what the heck.. and now a backup for EFS? what for? are they trying to get us EFS immigrants paranoid again for extra bucks?!!!

    1. overunder

      Re: Not so secret secret

      I think your point is overlooked in this article. Yes, it seems the next logical move is to sell a service to backup the backup of the backup. You know, eventually your going to be better off with your own hardware (you are already, but learning curves apply).

      But yeh, seems like a scare tactic to take even more money.

    2. K Silver badge

      Re: Not so secret secret

      Fight Backup club only has 1 rule - you can never have enough backups!

  14. Anonymous South African Coward Silver badge

    How long before we hear of somebody whose unencrypted and unsecured backup data got snaffled?

  15. Milton Silver badge

    "It frees the staff to genuinely innovate ..."

    Someone BTL wrote about the vritue of having Hadoop (in this case) on the "cloud" to free up folks from administrative chores because

    "It frees the staff to genuinely innovate ..."

    —which is true in principle, but the word "innovation" is actually almost universally misused.

    Speaking to developers, engineers and designers from aerospace to software, let me ask you to give me an honest answer: how many times have you truly innovated something—something imaginative, fresh and new, not resembling or based on prior work and art, something which might even be genuinely deserving of a proper patent?

    The answer for almost all of us is: Never. In my entire life (second career, where I moved from uniformed life to electronics and then computing 1992-onwards) I have occasionally solved problems others hadn't (hadn't: not couldn't) maybe four or five times and only one of those might conceivably have been patentable (a seemingly novel use of a phased locked loop, if you're interested, which because it ultimately seemed deducible to me, I couldn't be arsed to try to secure as IP). I've designed and written software from 6502 ASM through Ada and C++ to PHP and Python, for things ranging from stuff that arrives with a bang, boring machines, websites, heavy high-volumec integration to databases and you name it—a trajectory not so very special or different from many others here, I'm sure—and even 95% of the most intractable problems were solved by looking for examples elsewhere. We all learned an age ago that the wheel has been invented and refined and that if you poke around, your "uniquely difficult problem" has, in fact, already been solved by someone else.

    The truth is, we do not innovate. We incrementalise. Just like aerospace, where people yap on endlessly about "innovation"—and yet when you actually look at its history since the B707 of the 1950s, you realise progress has actually been a very slow and cautious incremental adoption of newer technologies, materials, fabrication techniques, design methods and engineering processes. The nearest thing to true innovation was Concord: the rest has all been slow and painstaking tiny improvements (understandably, given the costs and risks involved). Even SpaceX (a great "innovator"?) is merely doing things first suggested over half a century ago, enabled now by miniaturised computing power and a giant pile of cash. The last really innovative idea in space was Orion/Daedalus in the early 60s, a system that could have put huge self-sustaining colonies on Mars and opened the entire solar system in a decade, which we turned away from even now, because fallout might cause one or two extra thyroid cancers a year in the worlwide population.

    The point of this? Let's stop pretending tech is full of innovative geniuses inventing radical new ideas and gadgets. It isn't. We aren't. We are, as ever, crawling towards doing things slightly better this year than last, while frequently backsliding into expensive, swampy backwaters like "cloud" because we are lazy and beancounters have a maximum planning horizon of 12 months.

    As an exercise for the reader, I leave this provocative conjecture on the page: "The arrival of universal very high bandwidth anywhere-to-anywhere communication (the 56kB+> internet) has actually been a cultural, political, educational and innovation-hostile disaster for humanity. Discuss."

    .

    "proper patent", i.e. outwith of USPTO practice and current unfit-for-purpose US patent law

  16. bobsyouruncle

    Red rag to a bull?

    "One of the indie vendor insiders we spoke to was quick to assure The Reg that, for example, with AWS Backup you can't push a workload from AWS to Azure, which you can with this, and other independent vendors' service."

    I'm sure Amazon will sort that out and work it to their advantage - even though it doesn't immediately look like they would benefit from such a "feature"

  17. UnkDB

    Am I missing something?

    https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html says "Snapshots are incremental backups..." so if my application is in AWS, why do I need another backup?

    If they were offering me the ability (and I think they are) to backup my on-prem to an off-site facility (the so called cloud), I kind of get it.

    1. david.channon

      Re: Am I missing something?

      Snapshots are optional. You can take them manually ( e.g. before doing some work ) - and you can also setup them to run automatically like this:

      https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/TakeScheduledSnapshot.html

      However that does not "clean them up" after e.g. 30 days - so if you took daily snapshots you end up with hundreds.

      So you would end up doing things like this:

      https://aws.amazon.com/blogs/compute/automating-amazon-ebs-snapshot-management-with-aws-step-functions-and-amazon-cloudwatch-events/

      So one thing this backup service does do is smooth over a lot of the cracks - make it easy to configure/setup and verify ( in the sense of checking it has been done ).

      At the end of the day one of the biggest differences between Cloud Providers and any sort of hosting previously is that AWS is targeting everyone. From simple updated twice a year static sites on S3 - to tiny wordpres installs - to large websites - to huge enterprise grade setups that could be using various things.

      As a result not all services they offer are for meant or suitable for everyone - I would think this falls into this category.

      Standardised easy to setup cheap backups that can be done correctly by semi-technical users ( or new to AWS techs - or just busy techs in small companies ) is a very welcome addition.

      For example i've worked with a small-ish company previously where money was limited, so backup solutions and time invested were not approved. In that case the CTO ( who obviously had root access, his company, his aws account etc ) decided to "clean up" the AWS account - and deleted the Aurora Cluster running 30 or so sites AND declined the option to take a final snapshot ( which in AWS you have to purposefully NOT do ). So the cluster was gone, all previous snapshots and point in time recovery, and no final snapshot.

      This kind of quick ready to go backup service for that company would of been perfect to have as an alternative running to protect against that insanity.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019