All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Bad Experience. Namecrane Support Ignore The Ticket More Than 3d
LightBlade
Member
Hi,
i dont want make it public, but leaving 3 days with no answer or help, make me stress and bad.
we have a such bad experience with namecrane. we subscribe for managed mysql database but got an issue that single db drop the table by the user.
let me explain before we jump to namecranw
at first time join a beta then couple of month test all working fine. backup is run, i can see the progress backup and download it.
and in oct 2025 we try move some db to them, but found out in Jan 9, 2026. We dont have any backup anymore. no thing works in they are site, even if they say this product “Managed MySQL”.
how that become “Managed” if there is no such feature backup available. even they dont say anything like they backup is not working. or helping to find a solution.
then i open ticket at friday, then he answer it say they dont have any backup from oct 31, 2025. thats 2 month ago.
i ask nicely if we can get any new backup or restore, i can spend upto 100 USD to handle the restoration (im not asking for free if he dont want do it for free). 3 days laters still no answer. open new ticket getting merge with old one. ask in discord getting ignored too.
now my db is gone, my bad is trust the provider soo much. now my business getting impact and probably close soon.
im lost hope getting my backup or data back since they look like didn’t care about my data.
hope other people take carefully.
Comments
inb4 the swarm
Huh?
Where's your own backup?
If you don't have, the data is unimportant to you.
Hello,
That's in my queue and I was tied up on some other projects, sorry about that.
The current setup is on top of LXC containers and no matter how much tweaking we do, the backup systems keep getting killed off. We used LXC since we wanted ZFS compression/etc, but backups are still chewing up tons of space anyway.
We're going to schedule maintenance throughout the 2nd half of this month and we'll just rebuild things and I expect that to fix backups getting randomly killed.
We don't have logbin enabled due to how quickly it'll blow up space usage.
EDIT - to add to this, this wasn't any 'loss' on our end, the client wiped their own data, its just the auto backups we include haven't been firing properly.
Francisco
Customer warns people to 'becareful', but customer does not keep backup themselves 🤡
Sure, they should've been careful.
With that being said, backups should be working but they aren't. I've "fixed" them a half dozen times but each time it just doesn't behave properly. So, the fix is to simply rip/replace how SQL's currently handled.
I'll take it as a good time to upgrade to the latest GA/LTS MariaDB.
Francisco
On a Friday, and you opened this thread on a Monday. Your LET host didn't reply over the weekend? Oh no!
@Francisco By blowing up space, did you concider, allocate double space for every plan? How would it be, if a example, a 50GB DB would be backupped on a 2nd node, and has a max of that 50GB, without access to raise?
We try to keep like 30 days of rolling backups for people so things pile up. In NL we have nearly 2TB+ of gzip'd backups.
We have a very sizable cluster just for backup storage so I think the better option is to move them there, that way it has 100's of TB's available. With the added benefit that they're now remote
Francisco
I understand your frustration, and I do not dismiss the stress you are describing. However, I want to point out that making this public should not be the first course of action, especially when there are still private escalation paths available.
If you feel that support responses are too slow or inadequate, the more transparent and constructive approach would be to directly contact the owner of the business and clearly address your concerns there. Escalating privately gives the business an opportunity to review the situation at a higher level and respond appropriately, without unnecessary public pressure.
Going public before exhausting direct communication channels often escalates tension rather than resolving the issue. Reaching out to ownership would be a clearer and more effective way to seek accountability and clarification on what went wrong, particularly for something as serious as backups in a managed service.
Fuck this bootlicker guy. Provider has non working backups for two months without letting users know. Failing backups would be an escalation event if still an issue after 3 days at professional companies. This is Mickey Mouse shit.
Backups are an advertised feature in this case. It is paid. This is provider's fault and provider's mistake for not working, especially when they knew about it but did not put some official announcement with regards to maintenance or something.
This isn't a global issue for us, its a single location that bugged out with it. Of all the locations offering the product, SG's the only one that had an active fault. The others generally recover via auto cron restarts we do, etc. For whatever reason supervisor didn't want to do so in SG.
That doesn't excuse it though and you're right, we state its supposed to be there.
I've already been working on prepping the new systems and hope to get emails out sometime this/next week with most maintenance windows taking < 1h to complete.
I didn't want to do this work through the holidays for obvious reasons.
Francisco
>gzip in 2025 2026
Use
zstd! It's much faster at significantly better compression ratios.Also, if your backups are already compressed, ZFS compression won't do much. But I guess here you might mean your production systems hosting the db, not the backup systems.
We do gzip since we serve those to users to download and not everyone has something that covers zstd
Gzip is covered almost as well as zip.
Francisco
Lucky me I did not select them.
You sure? Here in NL I don't have a single backup of my monstrous 60GB database. I have backups for that smaller 300kB one, but none for this. We talked here, you said SSL, you fixed, still no backups. It's marked as
FAILEDfor 2-3 days in panel and then logs entries are deleted (LOL btw?)You can pm me the database name but I was on NL earlier and it was just fine. Maybe it’s timing out or getting smacked by oom killer w/o logs for it.
I wonder if you’re the mega database that has like 600g on disk of backups….
But, let’s get things swapped and go from there.
Francisco
My general impression is too much reliance is on "we'll just restart the service over and over". At least that's what it looked like with all the several minutes of downtime when hosted on the DA shared hosting.
Last 24 hours uptime: 93.3333% (93.3333%)
Last 7 days uptime: 98.4425% (98.4425%)
Last 30 days uptime: 97.7176% (97.7176%)
Also, not enough man power if a managed service can't be resolved for all that time.
Given that he shows 0 backups of that database, does anything tingle in your head you should look at the age and source of those 600GB backups that may or may not be orphaned?
We already chatted in PM about his backups and showed the growth on it.
We have maintenance windows set for Friday and Saturday to overhaul the setup as well as bring mariadb up to 11.8, thr latest LTS.
Francisco
What a crybaby they are.
Sorry if I'm off here, but does this hiccup affect the email service as well?
No this is just the offloadsql in Singapore.
We will have to do a maintenance on one of the mail servers at some point but I’m not rushing at the moment
Francisco
What's the current status of mail-related products?
Users should keep their own backups - they absolutely should.
Service failures also happen - nothing is 100% reliable all the time.
The issue I see here is that backups are an advertised, paid feature of a managed database service, they were known internally to be unreliable for an extended period, and users were not notified so they could mitigate the risk on their side.
Those two things combined made this a problem for the customer(s).
Backup services have been problematic for 5-6 months.
Backups weren't working properly.
This user experienced this because there were no backups.
But if the backups had worked properly, perhaps there wouldn't have been a problem.
But when a problem is written here, it's fixed immediately.
We've waited for days, even weeks, for answers in their own support systems.
In a way, it's very good to write about it here.
Now, what happened? They downgraded all nodes for 5-6 hours, then there was a 45-minute downtime, and the backups were made.
Now they will be doing an upgrade in the coming days. Let's see, we're waiting.
But everything shouldn't be handled through this forum; take it seriously and be a problem solver on your own system as well.
us1 has a temp OS drive we'll want to replace at some point. We got a hint at the possible source of the night time burps, we'll see tonight if a change helped. Basically, Smartermail is gobbling so much ram in a single process that it was (possibly?) hitting a limit. I bumped the limit 4x and have logging in place firing every second to log the current usage to see if that really was the case.
Fingers crossed!
Sorry, what did we downgrade?
The change out will allow us to keep many more sets of backups as well (at least 2). The first being local filesystem snapshots via ZFS. With the current container setup its messy and hasn't really worked right. Then there'll be the backups off to remote. We might throw in a 3rd 'full node' snapshot for the fun of it, but we'll see.
I've just not had a happy time with the containers. At first it was good for the IOPs but with some recent KVM changes we've been able to make we've seen a ~6x improvement to the point its not really worth it to containerize anymore.
Its a pain in the ass if we ever want to move things between servers since we can't live migrate them amongst all the other quirks.
Francisco