New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
To be enitrely fair ~they didnt kill the server, the hardware itself failed
unfortunately this is a risk, though their snapshot feature that supposedly wasn't working for some users is very unfortunate. I'd suggest that compensation was awarded to those users in specific. Always have another backup, perhaps weekly, off-site.
I'm not a provider and I agree with everyone else, you must keep your own backups. I know how much it can suck to lose data and I'm sorry that it happened to you but you can prevent this from now on by taking some simple steps.
Pickup some cheap storage vpses and rsync your important files over to those daily, keep local copies of them too, and combine it all with snapshots at Dediserve or wherever and then that way if something happens to your server or your snapshots fail or you accidentally mess something up you know that you have backups. You can find many bash scripts through Google that will give you some nice backup scripts.
People here are just trying to help you from getting screwed again in the future.
..and that is why you back up your own stuff.
I am not a provider nor I will ever be one. You are totally wrong in this. You buy what you pay. How much did DS server cost for you? Do you even know what is the extra cost for a provider to have daily and weekly offsite backups for all of his infrastructure, along with providing the initial service? This cost cannot be covered by what you have paid to Dediserve. That's why, everyone buys a vps for a little $$ per month or even a year, should not expect features that providers of 50 or 100$ per month offers.
If you are not willing to take your offsite AND offline backups daily or more frequently, if you are not willing to have a live spear server in case your basic provider goes off line, if you are not willing to actively monitor all of your infrastructure and see the marks of a potential fail danger, then, you should not buy an unmanaged server but a managed one, and not for cheap.
In my servers, I have at least TWO daily backups in TWO different places. For more critical tasks, I keep backups of the websites, the database, a backup from the whole control panel or the vps and, when hosted in my dedis, backups of the vm. And, except the daily backups, I keep weekly and monthly and I download from time to time backups in my local pc. Never use as backup the provider that provides the main hosting.
Crazy? Not really... This is the way you should go. So, stop whining and admit to yourself that it is totally your mistake because a cheap hosting provider has absolutely no obligation to keep backups.
Last but not least: It is better to use 6-7 of cheap or even dirty cheap providers to create a real fail proof setup, instead to spend the same amount in only one provider and put all your eggs there... That's why cheap providers are extremely useful for all of us, if they can provide a decent service. And a decent service is speed and performance, not having backups at all!
That's my point too. I don't get any sorry, any compensation. I'm never against the idea of customer should have their own backup somewhere else, my other point is provider should have backup for their mistakes too. Saying like people here, it is only a risk for customer, never a risk for provider, never a single case is a error from provider. Because backup of backup can fail too, provider can do whatever with their server, make it dead, delete it, overuse it, and it is always customer to blame for not having their own backup.
To you all: i totally understand that i should have my own backup if i want to make sure it is safe. I just want to say this to providers: you should have your own backup too in case you screw it up. And if you let that happens, at least say sorry to customer, at the end of the day, it is because of your hardware that i loose my data. Backup is just a solution, it is not the reason i lost my data. There is nothing i can get my data back now, but if you really care about your business, your product quality, you should improve your snapshot system, make alert message when it fails, suggest customer to buy more, make data backup when you change your server hardware, do not rely 100% on customer backup if you want to maintain a good service. T
Then they should not advertise and charge for supposedly safe snapshot backup storage. Why everyone talk about price he paid for hosting anyway? He paid extra money for backup storage.
Most people here are aware that no host is buletproof and familiar with "more backups the better" logic however this does not the change fact that if you're willing to take money for something you better deliver it.
"We use separate, dedicated NAS arrays to store your backups, ensuring you have immunity from any potential SAN or primary disk issues.
The NAS arrays are colocated on site with the clouds, but in seperate racks.
You have a set amount of Snapshot storage in your resource pool, which you can scale if you need more."
On a side note I experienced dediserve "Unable to create backup at this time - you've reached your backups limit" snapshot reliability in 2014 too. They fixed it for me after my report but meh...
Always when such issue arise we talk about clients responsibility. I am fine with that. But what annoy me here is that this by default exclude hosts responsibility.
Advertising and taking money for something what you're not able to deliver is hosts responsibility.
@magentoadmin
I doesn't matter who's fault it is. Your data is not coming back.
Why play the "blame game"?
Bottom line, keep your own backups and avoid relying on a single provider's "backups".
Ever tried to backup a node full of active running KVM instances? Might not be as easy as you think.
Assuming they're KVM, I don't even know. Point being that if you don't have access to the inside of the VM's disk, backing up regularly without customer action is not always a reliable solution. Mileage may vary by type of disk image used and virtualization.
To explain my understanding... take out your camera phone and try to take a picture of something that never stops moving. Do any of your images come out clear? The result of taking a live snapshot of a running VM, where you do not have access to the internal file system, can be similar to that. A flawed, corrupted image. Most notably in reference to InnoDB databases.
Certainly I acknowledge that backing up live VMs (besides openvz) is not my area of expertise, so someone may correct me on where this is or is not relevant, or why it may or may not be relevant to dediserve, but it's still something to consider. Backups are not always as easy as an rsync, from a host perspective.
Aaaaaand my box is gone again. Downtime
And back again...
OP didn't read the manual.
10gb of snapshot storage is mentioned on order page .
Buying enough Snapshot storage would have been the least labor intensive backup-restore solution, if you're already a dediserve customer.
It's kinda sad, because its such an easy way to do rollbacks to a fresh VM.
Ideally, yes, you should have offsite backups too.
The NAS might go FUBAR too some day.
( @emre22 )
We're incredibly sorry about the array issue, and are still working with HP to understand what actually happened. (In short, the drive failed in the array, but the array didn't seem to 'notice'). We spend more than most providers on our hardware, and our arrays are designed to tolerate many kinds of issues, but not one where a disk has failed but the controller keeps sending it data.
OP - if you can PM me a ticket ID I'd be happy to see if I can help you more - opening users here or WHT won't help the issue as much as asking for your concerns to be escalated to a manager - I'll certainly try to do all I can and can investigate more completely why your snapshot failed.
As has been said above, we specifically advertise snapshots NOT to be a backup solution, and provide mountable NAS for you to store your rsync/virtualmin/cpanel/manual backups to on any frequency you like (many customers also buy a small VM in another location for backups too). All Snapshots are stored externally to the clouds on adjacent Synology enterprise NAS clusters, so they do provide the ability to recover from Hypervisor related issues, we can also migrate VMs between Hypervisors on our platform, but in a case like this, the Storage was the problem, rendering that option impossible.
When all is said and done, we pride ourselves and build our business on the back of our enterprise hardware, 24/7 support and excellent uptime record, so even an issue with a single blade array, impacting a half dozen customers frustrates us hugely. I would encourage anyone impacted who has not already, to escalate their tickets to management and request SLA credits.
@dediserve
My box was turned off yesterday AGAIN, because some of the users used snapshots too much. So if I wouldnt notice it, my box still would be off.
No notification, no nothing. Only cheap excuses
Hi @emre22 I can see you spoke with the team on livechat about 8 hours ago, there was afollow up power cycle at HV level yes, nothing to do with snapshots, and your VM was stopped and started up again once the reboot completed.
Qcow2 images can be snapshot live, however the state of the system will be the same as if you just turn the power off your PC and turn it on again, so filesystem needs to be checked. Same goes for InnoDB tables mentioned in your post.
So basically you are running with no backups and no server monitoring system in place.
Not the way to do it.
I can only guess what security must be like.