How I Rebuilt Suvastika.com From Scratch After a Ransomware Attack
On the 30th of April, I was in a taxi heading to Mumbai with my family for a personal event. Somewhere on the highway, my phone rang. It was Submeet — calling to say that suvastika.com was completely down. Not just slow. Down. The cPanel wasn’t opening even with correct credentials. Could I check?
I was mid-journey, hours from home. I told him I’d look at it when I got back.
That call turned into one of the most intense, most educational, and most humbling projects of my career.
The Discovery
I returned from Mumbai on the 4th of May. Within hours of getting home, I was at my desk trying to figure out what had happened to suvastika.com — the website of Su-vastika Systems, a company I deeply respect, built by my mentor Mr. Kunwer Sachdev.
I don’t come from a core computer science background. Servers, terminals, cPanel internals — none of this was familiar territory. So I did what I’ve learned to do when I’m out of my depth: I used AI to guide me through it step by step.
With trial and error, failed commands, and a lot of patience, I managed to get into the cPanel. Inside, I started looking for clues — but the technical landscape was foreign to me. I pulled up the terminal inside cPanel and, with AI assistance, started running diagnostic commands.
What we found stopped me cold.
The site had been hit by a .sorry ransomware attack. Every media file, every design file, every WordPress file — encrypted. The attackers had locked everything and left their signature extension on every file. The website didn’t just go down. It had been systematically destroyed from the inside.
I called Submeet immediately. We had a brief, frank conversation about the situation — what we were looking at, what options existed, whether there was any path to recovery. Then I called Mr. Kunwer Sachdev.
The Decision That Changed Everything
When I explained the ransomware attack to Kunwer sir, his response was immediate and decisive.
Don’t try to recover WordPress. Build something new.
His reasoning was clear: WordPress is the most targeted platform on the internet. It had been the right choice at the time, but its popularity makes it a permanent target for exactly this kind of attack. Su-vastika needed a custom-coded website — something built from the ground up, not dependent on a platform that attackers know better than most developers do.
So the recovery plan became a rebuild plan.
The first thing I did was salvage what I could. The encrypted files were gone, but the written content — blog posts, news articles, product descriptions — existed in other forms. I fetched everything I could find and saved it locally. That text content became the foundation of what came next.
Building the New Website
I knew how to build a custom website. That part I was confident in. I started working on the UI for the new suvastika.com — a fully custom-coded site with no WordPress dependency, built to be fast, secure, and maintainable.
As the design took shape, I shared progress with Kunwer sir and Submeet. Feedback came in, adjustments were made. Alongside the website itself, I built a custom CMS tool — a content management interface that allowed the Su-vastika team to update any content on the site without touching code. For a company that publishes blogs, news articles, and product updates regularly, this was non-negotiable.
Three weeks of work. The structure was solid, the CMS was functional, and the site was taking shape.
But there was one problem we hadn’t solved: the images were gone.
Product photos. Blog images. News article visuals. Everything that had been stored in the WordPress media library was encrypted and unrecoverable. Three weeks in, we still had a website with missing visuals.
The Lesson I Needed to Learn
Then Kunwer sir called me.
He said I had worked half-heartedly on suvastika.
I was confused. I had put genuine effort into every part of this rebuild. I pushed back, internally, on the assessment. Then he said: he had found something I had missed entirely.
Web Archive — the Wayback Machine — had crawled and saved older versions of suvastika.com, including all the images, all the blog content, all the product visuals. Everything I had been stuck without for days was sitting in a public archive, one search away.
I had jumped straight into building without exhausting every avenue for data recovery first. He had spent more time on the problem before moving to solutions — and found the answer I had given up on.
That conversation was uncomfortable. But it was one of the most valuable corrections I’ve received. The lesson wasn’t just about Web Archive. It was about the difference between grinding on the wrong thing and grinding on the right thing. I had been working hard. I had not been working thoroughly.
There is always one more thing to try. Giving up one step too early might cost you exactly the solution you needed.
The Technical Challenge Nobody Warned Me About
With the images recovered and the site structurally complete, a different challenge emerged — one I hadn’t anticipated at all.
Suvastika.com had spent years building domain authority, SEO rankings, and search visibility. Mr. Sachdev had invested significant time, money, and effort into that digital presence. A site migration that changed the URL structure would destroy all of it — existing search rankings, indexed pages, inbound links — in one deployment.
I come from a non-digital-marketing background. URL preservation, 301 redirects, SEO migrations — these were not terms I was fluent in. But I understood the stakes clearly enough: if the new site launched with different URLs, years of work would evaporate.
So I learned. AI helped me understand how URL preservation works and why it matters. I researched how to extract every existing URL from the old site’s structure, understand the patterns, and map each one to the corresponding page on the new site. Then I implemented it.
The final count: approximately 300 page URLs and nearly 3,000 attachment URLs — all mapped and preserved through the migration. Every old link still works. The domain authority built over years transferred intact to the new site.
What This Project Taught Me
Suvastika.com is fully functional now. The team publishes content regularly. The site is faster, more secure, and more maintainable than the WordPress installation it replaced.
But the things I carry from this project have nothing to do with code.
Don’t build before you’ve fully assessed. I jumped into building because building is what I knew. Kunwer sir found the archive because he stayed in problem-solving mode longer than I did. Planning before execution isn’t a delay — it’s how you avoid three weeks of unnecessary work.
Discomfort from a mentor is a gift. Being told I worked half-heartedly, when I believed I had given everything, was jarring. But he was right in the way that mattered. A good mentor doesn’t protect you from hard truths — they deliver them at the moment you need them most.
The solution is often one step ahead of where you stopped. This is the one I think about most. At every point where I felt stuck, there was a path forward I hadn’t tried yet. Web Archive was obvious in hindsight. It’s always obvious in hindsight.
Working outside your domain is where the real growth is. Servers, terminals, SEO migrations, CMS architecture — none of this was my background. All of it is now part of how I think and work. Every unfamiliar problem I’ve pushed through has expanded what I’m capable of.
This project started with a phone call on a highway and ended with a rebuilt website, a recovered archive, and a version of myself that knows considerably more than the one who picked up that call.
If your website was built on WordPress and you haven’t thought about what happens when it goes down — think about it now. The question isn’t whether a WordPress site gets attacked. It’s when.
Related reading: From 503 to 200 OK: Diving into Server Management Under Pressure — another moment of being thrown into unfamiliar technical territory with no playbook. And: Navigating the Startup Hustle: Lessons from the Tech Trenches — on learning by doing when there’s no other option.