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.
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 ( …
COMMENTS
-
-
-
-
-
Friday 18th January 2019 09:06 GMT K
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?
-
-
-
-
Thursday 17th January 2019 18:07 GMT K
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!
-
Thursday 17th January 2019 20:40 GMT 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.
-
Friday 18th January 2019 06:46 GMT 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.
-
Friday 18th January 2019 12:49 GMT 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.
-
-
-
Friday 18th January 2019 08:54 GMT 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.
-
Friday 18th January 2019 18:21 GMT 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.
-
-
-
-
-
-
Thursday 17th January 2019 14:42 GMT hellwig
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?
-
-
Thursday 17th January 2019 16:46 GMT phuzz
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.
-
Thursday 17th January 2019 21:17 GMT hellwig
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.
-
-
-
-
Thursday 17th January 2019 15:47 GMT sabroni
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?
-
Thursday 17th January 2019 16:23 GMT 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.
-
Thursday 17th January 2019 17:24 GMT 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.
-
Thursday 17th January 2019 19:38 GMT 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.
-
-
Thursday 17th January 2019 17:50 GMT J. Cook
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.
-
Friday 18th January 2019 01:32 GMT 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?!!!
-
Friday 18th January 2019 05:19 GMT Anonymous Coward
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.
-
-
Friday 18th January 2019 09:31 GMT Milton
"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
-
Friday 18th January 2019 10:12 GMT Anonymous Coward
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"
-
Friday 18th January 2019 17:20 GMT 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.
-
Monday 21st January 2019 07:00 GMT 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.
-
-
Tuesday 14th May 2019 09:16 GMT Anonymous Coward
Cheap bulk object level backup is one thing, efficient and rapid restore/recovery to primary servers/arrays/ apps/users is another thing all together.
Back is boring, recovery is very exciting.
Gonna trust AWS for that? You'd be daft. AWS BU service is fine for snapping a gold copy in Cloud, for later backiing up to a 'proper' facility (as opposed to abucket of bits in a cloud on someone else's tin, and with no contro lof your meta data integrity.
Hands up who has recovered in anger and at pace from 'Cloud'? Thought so....
Many storage vendors can work with S3 bucket data for colo and unifiing on/off prem recovery plans.