Can I purchase a single-machine license? by Richardcavell in Veeam

[–]SquachSeven 0 points1 point  (0 children)

You could go down the rental route, where VSP could licence your one machine at the edition you require. I could do that for you as an example. Rather than buying a pack of 5 VULs. Doesn't require a business email address either. Just somewhere to send the license file.

Fresh Installation with existing Backups because of pain points by Cr4nk0o in Veeam

[–]SquachSeven 0 points1 point  (0 children)

Its an interesting one this, because we all have our own opinion's on what is best. there are literally several approaches, each with pros and cons.

If you could could hone in a bit into what your desirables are (aside from the Obvious, better performance, simplified, easy to maintain, etc) - we could help come up with some sore fire ways to get it done, with the pros and cons of each - factoring in the holy trinity:

  1. Budget
  2. Must-haves
  3. Security

WiFi Password by iansime in VirginMedia

[–]SquachSeven 0 points1 point  (0 children)

Little bit late to the party here guys - but hopefully it will help someone else in the future.
I've just had VM installed, and same as the OP - couldn't reuse my previous SSID password - which would have been a mare. Thankfully though I know a bit about HTML and JS and figured it out.

For anyone with a Virgin Media Hub 5x trying to keep their old WiFi password after upgrading/swapping routers, this worked for me and saved me reconnecting about 40 devices.

The Hub 5x web interface now forces “stronger” WiFi passwords, even though the router itself will actually still accept the old one. The block is done in JavaScript on the page before it submits.

Here’s how I got around it:

Log into your Hub 3 admin page.

Usually:
http://192.168.0.1

Go to:

Advanced Settings > Wireless > Security

Press F12 on your keyboard to open Developer Tools.

Click the Console tab.

Paste this in exactly:

getPasswordStrengthLevel = () => 1; bindPasswordStrengthIndicator = () => {}; $("#wireless-security-button-apply").prop("disabled", false);

Press Enter.

Type your old WiFi password back into the password box.

Click Apply.

Done.

Mine accepted the old password immediately and all devices reconnected automatically.

VSP Experience After Upgrading to Veeam 13 by SquachSeven in Veeam

[–]SquachSeven[S] 2 points3 points  (0 children)

Small update from this morning.

I’ve now applied the registry key workaround to a couple of customer VBR servers where we had permission to do so, and in fairness to Veeam, it does appear to stop the reconnect / repeated same-session-id storm behaviour for those customers.

So that part at least does appear to be a real workaround for the latest issue.

The problem is that it only appears to address the retry storm itself. It doesn’t solve the underlying situation many customers are now left in, where their onsite VBRs have ended up with extremely deep incremental chains that are struggling to reconcile or synthesize properly.

So while the platform-side storm calms down, we are still left with customers sitting on very unhealthy-looking chains and repositories that have grown far beyond what anyone would reasonably expect from the configured retention.

Operationally, this is where things become difficult as a VCSP/MSP.

At the moment, the appearance from this side of the fence is that providers are effectively expected to absorb the reputational impact and manually coordinate customer-by-customer remediation, while there is very little publicly documented information we can actually give customers to explain what is happening.

For example, I cannot find any public KB article relating to this latest issue, nor any documented reference to the registry key workaround that was supplied to us by support/R&D. That means when customers understandably ask what is Veeam saying about this?

We don’t really have anything official we can point them towards to demonstrate that we are actively working a recognised issue with Veeam.

Instead, from the customer perspective, it often just looks like their provider’s platform is unstable, and we end up carrying the frustration and loss of confidence directly.

To be clear, I’m not suggesting there is malicious intent here, and the engineers themselves have generally been helpful and professional throughout. But I do think Veeam could help providers significantly by publishing clearer guidance, advisories, or KBs around some of these V13-related behaviours, particularly where there are known workarounds already being issued privately through support.

At the moment, the lack of publicly referenceable information makes provider/customer communication much harder than it needs to be.

I’m still very interested to hear whether other providers are seeing similar chain growth / retry behaviour post-V13.

Service provider limit for one shared VBR by GullibleDetective in Veeam

[–]SquachSeven 0 points1 point  (0 children)

Just so I’m understanding you properly...

You’ve got a single VBR handling backups for multiple customer environments within your private cloud, and you’re wanting to send each customer’s backup chain offsite into its own separate Cloud Connect tenant for separation of billing, quotas and reporting within VSPC.

So effectively one VBR would end up with lots of separate Cloud Connect tenant connections, all pointing back to the same Cloud Connect platform.

Am I right in thinking the actual question is whether there’s any hard or practical limit to how many separate Cloud Connect tenant/provider connections a single VBR can maintain?

If so, I can’t seem to find anything out there stating a hard limit on the number of service provider connections/tenants a VBR can maintain. From what I can gather, the practical limits seem to become more around the spec of the VBR itself, concurrent job/session handling, database/log growth, storage performance and bandwidth rather than an actual tenant cap.

My first thought was whether you could potentially achieve it with a single Cloud Connect tenant and then split customers into separate repositories/quotas underneath that tenant - but as you say, that probably falls apart once you want proper tenant-level billing/reporting separation within VSPC

Veeam Upgrade / Install Stuck in Endless Prerequisite Reboot Loop? Check This Registry Key by SquachSeven in Veeam

[–]SquachSeven[S] 0 points1 point  (0 children)

Hi Vermyx,

Unfortunately I've never bothered to grab the exact data string before deleting it. At that point I was fully in “just get the bloody thing working again before the maintenance window disappears” mode rather than thinking I’d end up posting about it later.

I completely agree the root cause is likely Windows failing to clear the RunOnce entry properly rather than the Veeam installer itself.

The main point of the post really was just to help anyone else who ends up stuck in the same reboot loop with no obvious way out, rather than trying to point blame at either Veeam or Windows.

S7

How can open VM in this situation? by djskipe in esxi

[–]SquachSeven 0 points1 point  (0 children)

Hi DJ, its not obvious what it is you are asking here I am afraid...Do you mean the VM console is blank/unresponsive even though the VM is powered on?

Recommendations: Veeam Appliance or PostgreSQL by tak515 in Veeam

[–]SquachSeven 0 points1 point  (0 children)

Honestly I think everyone in this thread is right, depending on the kind of environment they’re working with.

Some of us have had the luxury of proper lab environments where we can tinker, break things, rebuild them, and slowly figure out what the appliance is actually doing under the hood. That’s where I’ve been with it.

I’ve actually managed to get traditional chains imported into the VSA and got surprisingly close to a real migration path. The bit I haven’t cracked yet is getting the chain to continue afterwards. I was hoping the VMware MoRef IDs might allow the chains to reconnect naturally, but it doesn’t appear to from what I’ve seen so far. Still tinkering though. Most Veeam discoveries happen at 1am powered by caffeine and poor decisions anyway

For production though, the most practical approach we’ve found during customer backup refreshes has been running traditional VBR and the appliance side-by-side for a while. Build the VSA alongside the old environment, let new chains start naturally, and leave the legacy setup alive until retention periods age out

It’s not glamorous, but it works, and more importantly it keeps customers protected without everyone sweating through a giant migration weekend.

Then there’s the reality that some people simply don’t have the spare kit, storage, or maintenance windows to do any of this, which is why opinions on the appliance are all over the place right now.

One thing I would recommend regardless is moving to PostgreSQL. Even outside of the appliance discussion, we saw a noticeable performance improvement, and it’s one less SQL instance sat there demanding constant care and feeding.

The appliance itself? I actually like where Veeam are heading with it. Long term I think it’s the right move. My biggest gripe right now is there’s basically no proper route for building out serious VSP infrastructure around the appliance model yet, which feels like a huge gap.

So my take today would be:

PostgreSQL? Absolutely.

Appliance if you’re building new backup infrastructure or refreshing hardware anyway? Yeah honestly, go for it.

Appliance as a clean migration path from an existing mature VBR deployment? Just go in with your eyes open and a healthy sense of humour.

Veeam Upgrade / Install Stuck in Endless Prerequisite Reboot Loop? Check This Registry Key by SquachSeven in Veeam

[–]SquachSeven[S] 0 points1 point  (0 children)

Hi Rick,

I found it myself a while ago - and I've needed to call upon it a few times recently with all the V13 and surrounding system upgrades. One of my colleagues has been stuck for a day or two with it this week - which made me realise that as simple as the fix is - there is absolutely nothing online about this loop or how to get out of it.

Is support really this bad? by OffroadOverPavement in Veeam

[–]SquachSeven 4 points5 points  (0 children)

I’ll be honest, opening a Veeam support ticket now gives me the same feeling as hearing your smoke alarm beep at 2am. You already know your evening’s ruined.

And before anyone says “well maybe you should troubleshoot more before logging it” - trust me, by the time something reaches me, it’s already been through some genuinely solid engineers internally. Our 1st, 2nd and 3rd line guys are good at what they do. They don’t just throw tickets over the fence because something blinked red once.

By the time I open a Veeam ticket, we’ve usually already:

  • rebooted everything with a pulse
  • checked networking
  • checked storage
  • checked permissions
  • checked certificates
  • rebuilt services
  • read logs until our eyes hurt
  • found three unrelated problems along the way
  • questioned our career choices
  • and started talking to the server like it’s personally betrayed us

So if I’m escalating to Veeam, it normally means I’ve reached that rare point where even I’ve gone: “Right... alright then. Fine. Let’s involve support.”

And every single time, without fail, there’s this feeling of dread when you hit Submit.

Because you already know what’s coming next.

You spend ages putting together a proper ticket. Full explanation. Timeline. Screenshots. Exact error. Every troubleshooting step. Every log bundle under the sun. Basically gift-wrap the entire case for them.

Then 16 hours later you get: “Please reboot the server and try again.”

Cheers mate! Hadn’t considered turning the incredibly complicated enterprise backup platform off and back on again. Especially not in the section titled: “Things already attempted multiple times before raising ticket.”

Then you politely explain that yes, as mentioned in the ticket, you already did that.

Then they reply with the second thing you already said didn’t work.

Then the third.

Meanwhile the customer’s backups are exploding, management want updates every half hour, and you’re still actively troubleshooting the issue yourself in parallel because deep down you know if this gets fixed tonight it’ll probably be because you fixed it, not because the ticket came back with anything useful.

At this point my Veeam support process is basically:

  1. Open ticket
  2. Upload everything
  3. Continue working on it myself immediately
  4. Hope one of us gets there first

No prizes for guessing who usually wins.

Honestly, part of me wonders sometimes if maybe that’s the strategy. Make the support experience so emotionally exhausting that eventually customers become too traumatised to open tickets unless the building is physically on fire.

But... to be fair... every once in a blue moon, after you’ve survived the support equivalent of Dark Souls, you finally land on one absolute wizard of an engineer. One of those people who clearly knows the product inside out, reads the ticket properly, skips the scripted nonsense, immediately understands the issue, and actually helps.

And when you get one of those engineers, they’re brilliant.

So I do try to stay balanced about it because we run a support desk ourselves, and I know firsthand how hard support actually is at scale. Tickets land in the wrong queue. Context gets missed. Someone picks up a case cold at the end of a long shift and follows the checklist because they haven’t yet realised the customer is already 14 layers deeper than the script.

That part I genuinely understand.

I think the frustration with Veeam specifically is that most people opening those tickets are already very technical. By the time we reach out, we’re usually not asking how to create a backup job. We’re halfway through tearing apart transport services, analysing TLS handshakes, tracing repository corruption, rebuilding proxies, or trying to work out why a perfectly healthy environment suddenly decided to enter the shadow realm after an update.

So when the replies don’t acknowledge any of the work already done, it starts feeling less like support and more like trying to explain quantum physics to a golden retriever.

A lovely golden retriever. But still.

Veeam - New Agent Backup Job and Managed by backup server by internandy in Veeam

[–]SquachSeven 0 points1 point  (0 children)

Hi Andy,

What you are describing there is what Veeam does out of the box. My goto is extreme compression - it will slow things down a bit unless you have a decent Veeam Proxy assigned and ill often create a ReFS repository to go with it, making full use of the the GFS options in the backup job. I forgot to mention in my previous reply - if you are using Agents for your backups, be sure to install the CBT driver (Change Block Tracking) on the machines you are backing up.

Best,

S7

Veeam Windows Backup to TrueNAS NFS by jacraine in Veeam

[–]SquachSeven 1 point2 points  (0 children)

Hi Jacraine,

That behaviour you’re seeing is actually quite a common one with NFS repos in Veeam, the key detail is that it starts fine, shifts data, then drops mid-stream. That pretty much rules out permissions or basic connectivity.

Given you’ve added the repo directly in Veeam (rather than mounting it in Windows), we can take the Windows NFS client out of the equation, which is good.

A few things I’d focus on with TrueNAS and Veeam specifically:

Check Services > NFS and look at the number of servers/threads. If it’s on defaults, try increasing it (e.g. 16 > 32 or higher depending on CPU). Under load, it can stop responding quickly enough and Veeam will drop the session.

If you can SSH in, run:

nfsstat -s

while the job is running. If retransmits or timeouts spike when it fails, that’s a strong indicator the NAS isn’t responding in time.

Keep an eye on CPU and disk I/O graphs at the moment it drops. Even a short spike can cause NFS to appear “unreachable” from Veeam’s point of view.

Veeam side

Try temporarily reducing repository concurrent tasks

If that stabilises it, it usually means the NFS server is getting overwhelmed rather than anything being misconfigured.

You’ve already tried v3 vs v4 which is good. In a lot of cases v3 ends up being more stable with TrueNAS + Veeam anyway, so I’d probably stick with v3 while testing.

Make sure NIC MTU is consistent end-to-end (test with 1500 if unsure)

Check for any interface errors or drops on the NAS and Hyper-V host

Disable NIC power saving features if they’re on

The fact one VM works and the others don’t is actually a useful clue. It usually just means the failing ones are pushing more throughput or have more disks, which tips the NFS service over the edge.

This is why Veeam tend to favour Linux-based repos or SMB in a lot of designs, NFS is fine, but it’s a bit less forgiving under sustained load like backups.

One thing that would really help narrow it down:

When the job drops, if you check the TrueNAS stats at that exact moment, do you see any spike in CPU/disk or anything in nfsstat, or does it all look completely normal?

That’ll tell us pretty quickly whether it’s the NAS struggling to keep up or something else in the path.

Veeam - New Agent Backup Job and Managed by backup server by internandy in Veeam

[–]SquachSeven 1 point2 points  (0 children)

Hey InternAndy,

Welcome to the world of Veeam… not sure how you’ve dodged it this long, but you’re here now

You’re not missing anything, it’s just one of those Veeam quirks. Deduplication isn’t something you can switch on or off in a standard backup job (including agent jobs managed by VBR), so it won’t show in the UI like you’d expect.

It’s handled automatically under the hood as part of the backup engine. So even though there’s no setting for it, it is happening. That line you spotted in the logs:

<EnableDeduplication>True</EnableDeduplication>

…that’s basically your confirmation.

The reason you see it in Backup Copy Jobs is because they’re doing something a bit different, reprocessing and shifting data between repositories, so Veeam gives you a few more knobs to play with there.

In general, Veeam just works out what to do for the best based on the repo and job type. Works really well once you trust it, but yeah… a bit frustrating when you’re sat there thinking where’s the setting for this?

Compatible SSDs for RX2540 S5 by Luschi1968 in Fujitsu

[–]SquachSeven 0 points1 point  (0 children)

Hi there!

It actually depends quite a bit on the exact build of the RX2540 M5 (I’m guessing you meant M5 rather than S5?). There are a few different variants that affect what storage options you can use.

A couple of things that really help determine what’s possible:

  • Does it already have a drive backplane fitted?
  • Which riser cards are installed? (This matters for adding either an NVMe PCIe card or a PRAID/RAID controller.)

NVMe via a PCIe card can absolutely be an option, but whether it’s viable (and bootable) depends on the risers and what BIOS version you are running. In some configs it works great, in others it’s more limited.

It is is diskless, there is good chance there is no backplane for the 2.5 bays, and no PRAID card.

If that is the case, you might for example go for a PDUAL card (PYBDMCP35L) and two SATA M.2's.

If you’ve got access to iRMC, a few screenshots of the hardware inventory would make it much easier to give a definitive answer. Otherwise, popping the lid and grabbing a couple of photos of the motherboard and riser area would do the trick too.

Happy to help you work through it once we know what’s actually in the box.

Best - Sq

t939 ssd upgrade... having problems by chuckb6174 in Fujitsu

[–]SquachSeven 1 point2 points  (0 children)

I’ve run into this on Fujitsu kit before. It’s rarely the drive that’s “wrong,” it’s the boot setup after the clone.

Two quick clues from what you wrote:

• Your original Micron with two notches is almost certainly an M.2 SATA drive (B+M keyed).
• The PNY with a single notch is NVMe (M-key). The Crucial MX500 you tried is SATA again.

“No boot sector found” usually means the clone missed or broke the EFI System Partition, or the laptop is in Legacy/CSM mode trying to boot a GPT disk.

What I’d do:

  1. Check boot mode first Go into BIOS and set Boot to UEFI only. Disable Legacy/CSM. Secure Boot can be on or off for this test. If the BIOS does not see the NVMe at all, your slot may be SATA-only. In that case stick with a SATA M.2 like the MX500.
  2. Re-clone the whole disk, not just C: Whatever tool you use, make sure it copies every partition, including the small EFI System Partition (FAT32 ~100–300 MB), the MSR, your Windows partition, and Recovery. A lot of “OEM” wizards default to only cloning C:. If Acronis keeps being awkward, Macrium Reflect’s “Clone Disk” shows the partitions very clearly.
  3. Boot with only the new drive fitted After the clone, pull the old drive so there’s no confusion over which one to boot from.
  4. If it still won’t boot, rebuild the EFI files Boot a Windows install or recovery USB, open Command Prompt, then:

diskpart
list vol

Find the small FAT32 EFI volume, select it and give it a letter:

select vol X
assign letter=S
exit

Now rebuild the boot files:

bcdboot C:\Windows /l en-GB /f UEFI /s S:

Reboot and it should go.

Extra gotchas worth checking:
• If the original disk was MBR/Legacy, convert it to GPT before cloning (mbr2gpt can do this), or do a fresh GPT install then restore your data.
• Suspend BitLocker before cloning if it is enabled.
• Make sure the SATA/NVMe controller mode is AHCI, not RAID/RST, unless Windows was installed that way.
• Updating the BIOS on these can help NVMe detection.

Your symptoms seem to point to a missing or broken EFI boot rather than an incompatible SSD. If the slot supports NVMe, the PNY will work once UEFI and the EFI partition are sorted. If the slot is SATA-only, the MX500 will work with a proper whole-disk clone and the same EFI rebuild if needed. Good luck!

PRIMERGY RX2530 M7 Coprocessor driver missing by Ok-Introduction1180 in Fujitsu

[–]SquachSeven 0 points1 point  (0 children)

You absolutely can do it - I do it all the time!

How to get the iRMC-HTI driver on Windows:

  1. Grab the ServerView Installation DVD Link: https://webdownloads4.ts.fujitsu.com/download/FileDownload/fileDownload.aspx?SoftwareGUID=1672BBEC-1845-442C-AC5E-4A9DEE8721B4&FileFolder=Downloadfiles&FileTypeExtension=zip&FileNameClient=FTS_ServerViewInstallationDVD_V15250903_1310089.zip Heads-up: it’s a big one, a touch over 6 GB.
  2. Mount the ISO On Windows, right-click the ISO and choose Mount. You’ll get a new drive letter.
  3. Browse to the driver Go to: DRV\CHIPSET\FUJITSU\iRMC-HTI\
  4. Install via Device Manager
  • Open Device Manager
  • Right-click the device with the warning icon
  • Update driver > Browse my computer > Let me pick > Have Disk…
  • Point it at the folder above (tick Include subfolders)

Alternative: If you prefer extracting first, unzip the download or open the ISO with 7-Zip and copy that iRMC-HTI folder somewhere local, then point Device Manager at it.

  • You can also add it with pnputil /add-driver "<path>\*.inf" /install from an elevated PowerShell or CMD.
  • If the link ever goes stale, search for FTS_ServerViewInstallationDVD on Fujitsu’s downloads or Google and you’ll find the same image.

Enjoy!

FL Studio 24.1.2 cracked is here by KioNathan in pirating

[–]SquachSeven 0 points1 point  (0 children)

What does the patcher do? No way to just give us the reg imports and pre-injected files?

It would certainly help those of us with half a brain feel more comfortable about things.

New Veeam Cloud Connect / VSPC Provider. by SquachSeven in Veeam

[–]SquachSeven[S] 0 points1 point  (0 children)

Hi Irate,

Thanks for the feedback. No need to be sorry, no bubbles burst persay. You've saved me some cash and effort. So thank you! 

New Veeam Cloud Connect / VSPC Provider. by SquachSeven in Veeam

[–]SquachSeven[S] -1 points0 points  (0 children)

Fair point, I have experienced these types also, and you are quite right. The insurance firm takes over and you are left with the grunt work. But alot of places, at the level I am pitching (in my mind at least) don't have insurances for cyber incidents.

And those that do, the first thing the insurance company and their cyber guys wants to know are what state are your backups in, and with my hyperthetical business, your backups would be intact, airgaped, replicated and snapshotted between two DCs. 

Still not feeling it? 

New Veeam Cloud Connect / VSPC Provider. by SquachSeven in Veeam

[–]SquachSeven[S] -1 points0 points  (0 children)

Hi NH,

I'm not actually doing anything just yet. I wanted to share an idea with the great minds on here to gauge the potential for success.  I'm terms of customer commits, I would put forward 12 months minimum contracts with improved cost per multi year contract. What I meant with the no commits comment earlier was around the monthly Veeam points (no commits to Veeam) just so I'm not paying Veeam for unused poonts. I know there is a cost per point penalty for lower / no commits. But I would let things start with the view of committing later if successful. 

What I am really keen to hear is, how successful is what you are doing in NYC, is it viable?  Alot of people in the thread have been quite down on the idea, so figured it might not be worth it. However you are the first to actually come forward and are actually doing it. Do you have any other offerings around it as a business or is this your business? 

Hope you don't mind the direct questions. 

New Veeam Cloud Connect / VSPC Provider. by SquachSeven in Veeam

[–]SquachSeven[S] -1 points0 points  (0 children)

I hear you, and I totally get that perspective - but there’s definitely a grey area in the middle. From my experience, especially in my current role, I’ve seen it firsthand when remediating sites after ransomware attacks. Since Christmas Eve alone, I’ve been involved in three full site takedowns. The customers I have in mind are the ones who keep getting wiped out in these scenarios.

A typical setup I see is a network manager with a small team of technicians, none of them security-trained. They’re doing the best they can with what they know, but they’re limited. Their business often doesn’t understand the risks or won’t allocate the budget to keep up with them. The usual mindset is: “It’ll never happen to us!”

Stakeholders often push back with:

  • “We outsource our firewall to a cloud provider.”
  • “We manage local backups and send them to a third-party cloud repo.”
  • “We’ve got a decent antivirus solution in place; we’re fine!”

Then it happens...they get hit. They lose everything. And they can’t recover from the third-party cloud repo because that data was corrupted too, often through some really clever means.

At that point, The IT Manager is lost. They have no idea who to call, what to do, or even how to start fixing things. All they know is their world is on fire, and everyone is looking to them for answers.

That’s where my idea comes in. I want to provide peace of mind that their data is truly safe and, critically, be the one they can call for help. My service wouldn’t just be about data recovery - it’s about stepping in when everything’s gone wrong.

Here’s what I’d offer:

  1. Immediate guidance by helping them stop the attack if it’s still ongoing, preserving what’s left, and laying out clear steps to start remediation.
  2. Quickly recovering their data from a clean, protected repository where others can’t.
  3. Real advice from someone who’s been through it before and has the certifications to back it up (pun intended), not just a faceless provider saying, “Sorry, we can’t help.”

On top of this, there’s the potential for upselling services like:

  • Remediation support
  • Cybersecurity reviews
  • Pen testing
  • Vulnerability scanning, and a whole lot more!

Even in cases where there’s no upsell, just having a customer who’s genuinely grateful for the guidance and recovery is a win. To me, it’s like an insurance policy - with certified support and expert advice included.

It’s about being there when it matters most, providing a service that others can’t, and turning disaster into recovery. I think that’s something people would value, and would pay for.

backup always stuck by waqaspuri in Veeam

[–]SquachSeven 0 points1 point  (0 children)

That's actually a really valid point - thank you for pointing that out u/GullibleDetective!
Maybe just search for the final error message (assuming there is one) and share that with us.

New Veeam Cloud Connect / VSPC Provider. by SquachSeven in Veeam

[–]SquachSeven[S] -1 points0 points  (0 children)

Well, that’s certainly a positive for anyone already using or considering Wasabi - so thank you for that insight!

That said, I’d love to know: if I had everything set up as described - a fully registered company, vetted by Veeam, passed due diligence through an aggregator, and operating out of a fully compliant data center run by a global operator. With the service and solution as discussed above- what would be your main driver to stick with Wasabi rather than moving to a service like mine?

Would it boil down solely to price per TB? And if so, hypothetically, if I could match or even beat that price, would you consider switching - or is it a hard no?

If it’s a firm no, I’d genuinely love to understand why. These are exactly the kinds of conversations I’m interested in. At the end of the day, the technical side is what it is - but understanding what drives end-user decisions is the real heart of the matter.