Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

The Cloudcone crash taught me a painful lesson.

jackpopsjackpops Member
edited January 31 in General

I only backed up my data on my VPS, not locally. I'd like to know if my VPS data can be recovered after your restore.

Could you please help me restore my data first? I haven't made a local backup.

Jaden W
40 minutes ago

Unfortunately, as the attacker had deleted all data, data recovery is not possible unless you have your own backups.

Please note we will be sending an email out with further detailed instructions soon on how to get back online.

Thank you for your patience and understanding.

--

Regards,

Jaden W - L1 Support Engineer
CloudCone Customer Support

When their VPS failed, my VPS data was unrecoverable. Because I had backed up my data on the VPS but not locally, all my websites were lost. Fortunately, those websites didn't have much traffic. This taught me a valuable lesson: for stable operation, I must find a reliable and stable VPS provider. This was the first time in my over ten years of using VPS that I encountered such a terrible situation.

Thanked by 1oloke

Comments

  • You didn't learn the more important lesson.

    Take backup so that you can restore it in a different server in matter of hours if not less.

  • @itachikonoha said:
    You didn't learn the more important lesson.

    Take backup so that you can restore it in a different server in matter of hours if not less.

    Yes, I only backed up the data on the VPS; I didn't back up the data to my local machine or another VPS.

    Thanked by 1oloke
  • @jackpops said:

    @itachikonoha said:
    You didn't learn the more important lesson.

    Take backup so that you can restore it in a different server in matter of hours if not less.

    Yes, I only backed up the data on the VPS; I didn't back up the data to my local machine or another VPS.

    Unfortunately painful data loss is the way most of us learn to take proper backups, (myself included).

    You should always make sure your backups are on a separate network, either a VPS with a different provider or local machine, (and ideally both).

    But just taking backups isn't enough. You also need a plan to restore them, and you need to test restoring them before the worst happens.

    Thanked by 3ralf emgh whynotlearn
  • yoursunnyyoursunny Member, IPv6 Advocate

    @CloudHopper said:
    But just taking backups isn't enough. You also need a plan to restore them, and you need to test restoring them before the worst happens.

    Our most precious data is in Seafile storage service.

    The first time we attempted a test restore, it was painful, but we got it working in a few hours.
    It was a valuable experience, and we took detailed notes on the procedure.
    Subsequently, we also retest this procedure after major upgrades, to ensure it still works the same way.

    Sometime later, we used the restoration procedure to migrate the instance between servers, instead of directly moving containers and volumes.
    During that time, we discovered that we have stored the Seafile restoration procedure within Seafile, which would be inaccessible in a disaster.
    We then established a daily rclone of the Seafile folder to a local folder.
    It can be read without restoring to Seafile software.

  • @yoursunny said:

    @CloudHopper said:
    But just taking backups isn't enough. You also need a plan to restore them, and you need to test restoring them before the worst happens.

    Our most precious data is in Seafile storage service.

    The first time we attempted a test restore, it was painful, but we got it working in a few hours.
    It was a valuable experience, and we took detailed notes on the procedure.
    Subsequently, we also retest this procedure after major upgrades, to ensure it still works the same way.

    Sometime later, we used the restoration procedure to migrate the instance between servers, instead of directly moving containers and volumes.
    During that time, we discovered that we have stored the Seafile restoration procedure within Seafile, which would be inaccessible in a disaster.
    We then established a daily rclone of the Seafile folder to a local folder.
    It can be read without restoring to Seafile software.

    I use seatable and face the same issue. It is a pain to restore everything. It is better to export the dtable file than restoring through official seatable procedure.

    How is seafile performance though?

  • how did they get hacked. this is really bad for smaller providers and customers

  • mp11mp11 Member

    think every 5yo knows that today.

  • @cybertech said:
    how did they get hacked. this is really bad for smaller providers and customers

    They got hacked because of a vulnerability in Virtualizor, and it seems they're not the only provider to have been breached recently due to the same issue:
    https://lowendtalk.com/discussion/214080/ransomware-via-virtualizor-exploit

    Thanked by 1whynotlearn
  • @CloudHopper said:

    @cybertech said:
    how did they get hacked. this is really bad for smaller providers and customers

    They got hacked because of a vulnerability in Virtualizor, and it seems they're not the only provider to have been breached recently due to the same issue:
    https://lowendtalk.com/discussion/214080/ransomware-via-virtualizor-exploit

    i thought their panel was in house. at least it looked the part

  • emghemgh Member, Megathread Squad

    @cybertech said:

    @CloudHopper said:

    @cybertech said:
    how did they get hacked. this is really bad for smaller providers and customers

    They got hacked because of a vulnerability in Virtualizor, and it seems they're not the only provider to have been breached recently due to the same issue:
    https://lowendtalk.com/discussion/214080/ransomware-via-virtualizor-exploit

    i thought their panel was in house. at least it looked the part

    Probably custom panel using Virtualizor API for backend VM functions

    Thanked by 2tentor cybertech
  • I migrate my services frequent enough between VPS of different providers and now I can restore my data from backup with closed eyes. That said, having backup is important (on remote storage) even though you're with a stable provider.

    Thanked by 1oloke
  • rpqurpqu Member

    Daily reminder

    Thanked by 1yoursunny
  • @rpqu said:
    Daily reminder

    Thanked by 1nghialele
  • Any provider can lose data, you didn't learn anything.

  • blip1945blip1945 Member
    edited January 31

    3-2-1 backup policy is mandatory. Even with gcp, aws, do, whatever supposedly the trusted, the most stable provider out there, shit can and will happen. Always baffled me when people yolo doesn't have self created backup then cry when shit happens.

    Thanked by 3oloke CloudHopper rpqu
  • @blip1945 said:
    3-2-1 backup policy is mandatory. Even with gcp, aws, do, whatever supposedly the trusted, the most stable provider out there, shit can and will happen. Always baffled me when people yolo doesn't have self created backup then cry when shit happens.

    With GCP, AWS, Azure and the other big clouds it's even more critical. They can delete your account and then you're absolutely f*cked, no matter how many of their regions and availability zones you've backed up to!

    Thanked by 2JohnnySac tentor
  • emghemgh Member, Megathread Squad

    @CloudHopper said:

    @blip1945 said:
    3-2-1 backup policy is mandatory. Even with gcp, aws, do, whatever supposedly the trusted, the most stable provider out there, shit can and will happen. Always baffled me when people yolo doesn't have self created backup then cry when shit happens.

    With GCP, AWS, Azure and the other big clouds it's even more critical.

    Why would GCP, AWS and Azure be more inclined to remove accounts than other clouds?

  • rpqurpqu Member
    edited January 31

    @emgh said:

    @CloudHopper said:

    @blip1945 said:
    3-2-1 backup policy is mandatory. Even with gcp, aws, do, whatever supposedly the trusted, the most stable provider out there, shit can and will happen. Always baffled me when people yolo doesn't have self created backup then cry when shit happens.

    With GCP, AWS, Azure and the other big clouds it's even more critical.

    Why would GCP, AWS and Azure be more inclined to remove accounts than other clouds?

    Because removing you doesn't hurt their bottom line nor their reputation. Even when the report is false, they could afford legal battle.
    If you don't have their sales rep. phone number, tread carefully.

    Thanked by 2CloudHopper MikeA
  • @emgh said:

    @CloudHopper said:

    @blip1945 said:
    3-2-1 backup policy is mandatory. Even with gcp, aws, do, whatever supposedly the trusted, the most stable provider out there, shit can and will happen. Always baffled me when people yolo doesn't have self created backup then cry when shit happens.

    With GCP, AWS, Azure and the other big clouds it's even more critical.

    Why would GCP, AWS and Azure be more inclined to remove accounts than other clouds?

    It's not that they're more inclined, it's just that they provide all their services across various regions so people tend to use them exclusively and assume that their backups are geographically distributed and therefore safe...so getting your account deleted by them is usually much worse than with other clouds.

    Thanked by 1emgh
  • emghemgh Member, Megathread Squad

    @rpqu said:

    @emgh said:

    @CloudHopper said:

    @blip1945 said:
    3-2-1 backup policy is mandatory. Even with gcp, aws, do, whatever supposedly the trusted, the most stable provider out there, shit can and will happen. Always baffled me when people yolo doesn't have self created backup then cry when shit happens.

    With GCP, AWS, Azure and the other big clouds it's even more critical.

    Why would GCP, AWS and Azure be more inclined to remove accounts than other clouds?

    Because removing you doesn't hurt their bottom line nor their reputation. Even when the report is false, they could afford legal battle.
    If you don't have their sales rep. phone number, tread carefully.

    I don't know about that, countless stories about shitty providers on LET acting like kids (because they are)

    I'm not saying GCP is perfect but let's not pretend come-and-ago LET hosts that stay alive for 3 hours + VAT are better in terms of acting professionally

  • MikeAMikeA Member, Patron Provider
    edited January 31

    @CloudHopper said:
    With GCP, AWS, Azure and the other big clouds it's even more critical. They can delete your account and then you're absolutely f*cked, no matter how many of their regions and availability zones you've backed up to!

    Probably a good thing. I tried Google Cloud two days ago and the CPU was so throttled a freshly installed VM would hang for 5 minutes and lock up running an apt upgrade. Made me realize how big cloud providers limit CPU so much and how good low end server people have it using VPS with $2 full CPU cores.

  • emghemgh Member, Megathread Squad

    @MikeA said:

    @CloudHopper said:
    With GCP, AWS, Azure and the other big clouds it's even more critical. They can delete your account and then you're absolutely f*cked, no matter how many of their regions and availability zones you've backed up to!

    Probably a good thing. I tried Google Cloud two days ago and the CPU was so throttled a freshly installed VM would hang for 5 minutes and lock up running an apt upgrade. Made me realize how big cloud providers limit CPU so much and how good low end server people have it using VPS with $2 full CPU cores.

    Their main use case isn't unmanaged VMs. They just exist because they have to.

    Thanked by 2mans_xd oloke
  • rpqurpqu Member
    edited January 31

    @emgh said:

    @rpqu said:

    @emgh said:

    @CloudHopper said:

    @blip1945 said:
    3-2-1 backup policy is mandatory. Even with gcp, aws, do, whatever supposedly the trusted, the most stable provider out there, shit can and will happen. Always baffled me when people yolo doesn't have self created backup then cry when shit happens.

    With GCP, AWS, Azure and the other big clouds it's even more critical.

    Why would GCP, AWS and Azure be more inclined to remove accounts than other clouds?

    Because removing you doesn't hurt their bottom line nor their reputation. Even when the report is false, they could afford legal battle.
    If you don't have their sales rep. phone number, tread carefully.

    I don't know about that, countless stories about shitty providers on LET acting like kids (because they are)

    I'm not saying GCP is perfect but let's not pretend come-and-ago LET hosts that stay alive for 3 hours + VAT are better in terms of acting professionally

    I think you're mistaken, it's not about professionalism. It's their policy.
    There's countless stories about people not given a chance to migrate decade worth of data because someone made a false report, which resulted in account ban, even on unrelated service.

    Have you ever heard the story of Prince waking up one day and decide to be less neutral?
    I believe some people also know the story of LFJ.

    Thanked by 1forest
  • emghemgh Member, Megathread Squad

    @rpqu said: There's countless stories about people not given a chance to migrate decade worth of data because someone made a false report, which resulted in account ban, even on unrelated service.

    Absolutely, and there's also countless of stories about LET providers shutting down overnight with no warning. It's just silly trying to say one is better than the other.

  • rpqurpqu Member

    @emgh said:

    @rpqu said: There's countless stories about people not given a chance to migrate decade worth of data because someone made a false report, which resulted in account ban, even on unrelated service.

    Absolutely, and there's also countless of stories about LET providers shutting down overnight with no warning. It's just silly trying to say one is better than the other.

    I don't think I made a statement which argued one of them is better than another. The emphasis is on "no warning".

    Thanked by 1emgh
  • @yoursunny said:

    @CloudHopper said:
    But just taking backups isn't enough. You also need a plan to restore them, and you need to test restoring them before the worst happens.

    Our most precious data is in Seafile storage service.

    The first time we attempted a test restore, it was painful, but we got it working in a few hours.
    It was a valuable experience, and we took detailed notes on the procedure.
    Subsequently, we also retest this procedure after major upgrades, to ensure it still works the same way.

    Sometime later, we used the restoration procedure to migrate the instance between servers, instead of directly moving containers and volumes.
    During that time, we discovered that we have stored the Seafile restoration procedure within Seafile, which would be inaccessible in a disaster.
    We then established a daily rclone of the Seafile folder to a local folder.
    It can be read without restoring to Seafile software.

    Do you have a detailed backup tutorial? Thank you. Does the backup method you shared only back up the website, or does it back up the entire VPS data? Thank you.

  • @truemagic said:
    I migrate my services frequent enough between VPS of different providers and now I can restore my data from backup with closed eyes. That said, having backup is important (on remote storage) even though you're with a stable provider.

    Do you have a detailed backup tutorial? Thank you. Does the backup method you shared only back up the website, or does it back up the entire VPS data? Thank you.

  • tentortentor Member, Host Rep
    edited February 1

    @emgh said:

    @rpqu said: There's countless stories about people not given a chance to migrate decade worth of data because someone made a false report, which resulted in account ban, even on unrelated service.

    Absolutely, and there's also countless of stories about LET providers shutting down overnight with no warning. It's just silly trying to say one is better than the other.

    Hey let's look positively - small LET hosts act as professional as big name clouds! "Industry best practice"!!

    Thanked by 1emgh
  • rpqurpqu Member
    edited February 1

    @tentor said:

    @emgh said:

    @rpqu said: There's countless stories about people not given a chance to migrate decade worth of data because someone made a false report, which resulted in account ban, even on unrelated service.

    Absolutely, and there's also countless of stories about LET providers shutting down overnight with no warning. It's just silly trying to say one is better than the other.

    Hey let's look positively - small LET hosts act as professional as big name clouds! "Industry best practice"!!


    I appreciate the humor, but it's quite serious.

    Thanked by 1tentor
Sign In or Register to comment.