May 2026
That is what the headline would read. And in a way, it is true: I undertook a large-scale data migration, determined upfront to use AI to get it done faster and more efficiently than I could alone. The bad actor here? Only me, even unintentionally. I am going to omit the specific tooling and models to protect the innocent — this was not based on my local setup but on publicly available tools. No point in throwing anyone under the bus.
---
A quick bit of backstory. I lost access to a large cross section of equipment in a house fire. The stuff I recovered was damaged, in most cases beyond repair. I will not go down the rabbithole of homeowners insurance here, but if you think it handles damage and replacement badly enough, just wait until you add home lab equipment. They have no idea how to process it.
The reality is that since the fire, I have operated with limits on what data I could access. About half was saved on drives I had in hand — I luckily recovered everything from 2018 onward from server-side drives I pulled. The other half, everything prior to 2018, was on servers and drives I never got back.
When I finally sorted out what was actually lost, I wanted to stop any further bleeding. I started out hoping to recover data lost in the fire, but quickly worked out I only had that one copy of everything post-2018 as well. When that penny dropped, I panicked. I started trying to mount and recover a second 24 TB ZFS array — data I no longer had access to. I had two sets of drives. One array came back up. The second was lost, too much damage to recover. When I finally lined up enough drive space, I could not move fast enough to get a good backup.
---
The migration. Getting that backup took the better part of a day, even over a 10 Gb link. And here is the critical distinction: a ZFS backup is not an rsync or a file copy. It is a block-level transfer of the current state of the array from one host to another. I could not afford to host two servers long-term, so my plan was to get a good copy onto the new array, then retire the old drives. I wanted a fallback if the worst came to pass again.
Getting the old drives online required spinning them up inside a VM with correct PCIe mapping. That part I have to thank AI for — it is a genuinely difficult process. I have done it on my own before, but I never would have thought to attempt it until I prompted my AI development agent to take a look. The 80/20 rule applied: there was no magic button. It took about a day to iron out the network passthrough issues, restore configurations, and work through the hardware mismatches inherent in any migration. After that, I jumped onto the old host and triggered the sync to the new one.
---
Here comes the train. If you have not seen it coming down the tracks yet, that is okay — neither did I.
The problem was simple: when the new system is just an empty dataset on a new pool, asking the old server to copy a backup to available space is a dream. You set it up, let it run, and aside from some basic permissions or client-side config, you are up and running as soon as the copy finishes.
But — and this is the whole point — when you take an existing array that you shut down two days ago while using your shiny new volume for all your puts and takes, the new volume ends up with more data than the old one. And a backup restore does not do a merge. A ZFS send/receive replaces the destination with the source's state. Period.
So the restore blanked out the two days of work I did in the rush to get everything running. I simply did not think through the difference in how the data flows — how the service actually works. A backup is not an rsync. The job effectively returned the drives to the state they were in when I started the cutover two days earlier.
---
The point. It is easy and exciting to blame AI. I fully expect there will be times when that may in fact be the root cause. But I think the more common problem will be the combination of new capabilities with rapid technology shifts and the sudden availability of "vibe coding" tools: less qualified people trying to sort out the underlying impact of changes they are making — or more likely, changes they are approving AI to make on their behalf.
To be clear: the old and new volumes have duplicated data, backed up and kept offline. The impact here was really just the time to go back and copy the files I had removed. AI never has access to any core system or service that is not backed up, or anything for which I do not have an alternative.
That should be the cornerstone of your policy on vibe coding: if you are using AI to help complete your work, you are responsible for the outcome of what AI does within the systems you have granted it access to. Not your vendor. Not the model. Not the agent. You.
I was the bad actor here. And that is the most honest thing I can write.
Built on a home lab, powered by local models, and owned by Andrew Katana.