Daily DevOps & .NET - Where Code Meets Culture

Your Azure SQL Backups Won't Save You (Here's Why)

Your Azure SQL Backups Won’t Save You (Here’s Why)

“We have backups” is the IT equivalent of “thoughts and prayers.” Comforting words that mean nothing when disaster strikes. I’ve watched teams discover their Azure SQL Database backups expired just before an audit, or worse, during an actual outage. The default seven-day retention feels generous until you need data from day eight.

Compliance standards demand information backup in cloud environments, but no standard can enforce what most teams ignore: actually testing those backups. The gap between “we configured backups” and “we can restore our data” has ended careers and companies. This isn’t about checking compliance boxes. It’s about whether your business survives the next outage.

Your Stack Traces Are Love Letters to Attackers

Your Stack Traces Are Love Letters to Attackers

Your exception handler returns detailed stack traces to be “helpful.” Congratulations, you’ve just handed attackers your internal file paths, database technology, and architecture details. This guide shows how to implement error handling that satisfies security audits: comprehensive internal logging paired with generic client responses, correlation IDs for support, and environment-aware middleware.
AKS Disaster Recovery: Why Your Untested Backup Will Fail

AKS Disaster Recovery: Why Your Untested Backup Will Fail

Your cluster will fail. The question is not if, but when, and whether you can recover before customers notice. Most organizations discover their backup strategy does not work during an actual outage, when recovery time matters most and manual heroics cannot save you.

If you run Azure Kubernetes Service (AKS) in production, you need a recovery plan that engineers can execute half asleep at 2 AM. We will go through what to back up, how Velero works in day-to-day operations, when Azure Backup for AKS is enough, and how to design realistic failover with measurable Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The goal is simple: repeatable recovery procedures you have already tested, not a document that looks good in Confluence but fails during an incident.

Nobody Runs Your Cleanup Script (And Regulators Know It)

Nobody Runs Your Cleanup Script (And Regulators Know It)

“Storage is cheap” — until your data retention strategy becomes evidence in a GDPR lawsuit.

After 15+ years in enterprise software, I’ve seen this pattern in project after project: elaborate wiki documentation, a cleanup script nobody runs, and production databases growing exponentially with personal data that should have been deleted years ago. The compliance checkbox is marked, but the actual deletion never happens.

When regulators investigate, they don’t want your policy documents. They want execution logs proving deletion actually happened. Azure Storage lifecycle policies, Cosmos DB TTL, and scheduled Functions give you exactly that — automated retention that runs without human intervention, with full audit trails.

Your Logout Button Is Lying: ASP.NET Session Security Done Right

Your Logout Button Is Lying: ASP.NET Session Security Done Right

That StackOverflow answer suggesting Session.Timeout = Int32.MaxValue for “better UX”? It’s how security becomes checkbox theater. Sessions that never expire, logout buttons that don’t invalidate tokens, cookies transmitted over HTTP—auditors catch these patterns immediately. Here’s how to configure ASP.NET Core authentication that actually works.