Private corporate batches, live online cohorts and 1-on-1 mentoring in Kubernetes backup, restore, cluster migration and rehearsed disaster recovery — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Velero from the restore backwards — what a real recovery scenario demands, then the backup design that satisfies it. The syllabus covers the decision most teams get wrong, which volume data path to use per workload across CSI snapshots, file-system backup and the data mover, then application-consistent backup with pre and post hooks, restore semantics including namespace mapping and existing-resource policy, and cross-cluster migration. Sessions run against real clusters and object storage, and every module ends in an actual restore, because an unverified backup is a belief rather than a control.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Velero that means a trainer who has run it in production — Kubernetes backup, restore, cluster migration and rehearsed disaster recovery — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Velero batchVelero is an open-source tool for backing up, restoring and migrating Kubernetes clusters. It protects two distinct things: the API objects that describe your workloads — deployments, services, CRDs, RBAC, ConfigMaps, secrets — and the data inside persistent volumes. Both are needed, and confusing them is the most common reason a restore fails when it matters.
Velero runs as a controller in the cluster plus a CLI. Everything it does is expressed as custom resources: Backup, Restore, Schedule, BackupStorageLocation and VolumeSnapshotLocation. Object data goes to an object store — S3, Azure Blob, GCS or anything S3-compatible such as MinIO — via a provider plugin. Volume data has more than one path, and choosing correctly per workload is a real design decision: CSI volume snapshots when the storage driver supports them, file-system backup with the Kopia or Restic uploader when it does not, and the built-in data mover when you want snapshot data lifted into object storage rather than left on the provider.
On top of that sit the features that make it usable in anger. Backup hooks run commands in a pod before and after a backup, so a database can be quiesced for a consistent copy. Label selectors, namespace and resource includes and excludes control scope. Schedules with cron expressions plus TTL give retention. Restores can target a different namespace, honour an existing-resource policy, apply JSON patches through resource modifiers, and follow a defined resource ordering — which is what makes Velero a cluster migration tool as well as a backup tool.
Kubernetes made infrastructure reproducible and gave a lot of teams false confidence about recovery. The manifests are in Git, so the argument goes, and the cluster can be rebuilt. That argument ignores everything created after apply: data in persistent volumes, secrets rotated in place, CRDs installed by operators, resources generated by controllers, and the accumulated state that no repository contains.
Meanwhile the failure modes have become more mundane and more frequent. A namespace deleted by an over-broad label selector. A bad Helm upgrade that removes a CRD and takes its custom resources with it. A cluster upgrade that has to be rolled back. Ransomware. A cloud region that goes away. None of these are exotic, and all of them are survivable with a rehearsed restore and unsurvivable without one.
Regulators and customers have noticed too. Recovery point and recovery time objectives now appear in security questionnaires and audit findings for Kubernetes platforms, and the evidence asked for is a tested restore, not a green backup job. Velero is the default answer in that space, and the skill gap is squarely on the restore side: most teams have backups running and have never proved they can bring a cluster back from them.
The problem before the tool. What is genuinely recoverable from Git and what is not, the difference between etcd snapshots and application backup, defining RPO and RTO for real workloads, and the failure scenarios worth designing against rather than the ones that sound dramatic.
Topics: Cluster state, application objects and volume data as three separate problems · etcd snapshots vs Velero: what each protects and what neither does · GitOps and the limits of declarative reconstruction · Defining RPO and RTO per workload tier · Failure scenarios: namespace deletion, bad upgrade, node loss, region loss, ransomware · Backup as a control: evidence, retention and audit expectations · Where Velero fits alongside storage-level snapshots and database-native backup
How Velero is put together and how to install it without leaving a credential problem behind. Server and CLI, provider plugins, BackupStorageLocation and VolumeSnapshotLocation, and identity done properly with IRSA, workload identity or scoped keys.
Topics: Velero server, CLI and the custom resource set · Provider plugins for AWS, Azure, GCP and S3-compatible stores · BackupStorageLocation: bucket layout, prefixes and read-only locations · VolumeSnapshotLocation and provider snapshot configuration · Credentials: IRSA, workload identity, service principals and scoped keys · Installing via CLI and via Helm, and configuring the deployment · Multiple storage locations and a default location · Verifying an installation before trusting it
Deciding what goes into a backup, which is where most misconfiguration lives. Namespace and resource includes and excludes, label selectors, the cluster-scoped resource question, ordering and TTL, then Schedules and what a retention policy really implies.
Topics: include-namespaces, exclude-namespaces and resource filters · Label selectors and the backup.velero.io exclusion label · Cluster-scoped resources: CRDs, ClusterRoles, PVs, namespaces themselves · What Velero skips by default and why · TTL, expiry and backup deletion mechanics · Schedules and cron expressions per workload tier · Backup phases: InProgress, Completed, PartiallyFailed and Failed · Reading velero backup describe --details and backup logs
The decision that determines whether your data is actually protected. CSI volume snapshots, file-system backup with the Kopia or Restic uploader, and the data mover — how each works, what each costs in time and storage, and which to pick per workload.
Topics: CSI VolumeSnapshot integration and VolumeSnapshotClass labelling · Provider-native snapshots and their portability limits · File-system backup: Kopia and Restic uploaders, opt-in vs opt-out · backup.velero.io volume annotations and defaultVolumesToFsBackup · The data mover: snapshot data lifted into object storage · Performance, cost and restore-time trade-offs of each path · Repository maintenance and encryption for file-system backup · Volumes that cannot be backed up safely and what to do instead
A crash-consistent copy of a database is a gamble. Pre and post backup hooks to quiesce and release, restore hooks to prepare a workload as it comes back, and the patterns for StatefulSets, databases and multi-pod applications where ordering matters.
Topics: Crash-consistent vs application-consistent backup · Pre and post backup hooks via annotations and backup spec · Container selection, commands, timeouts and failure behaviour · Quiescing common databases safely · Restore hooks: init containers and post-restore commands · StatefulSet backup: ordinals, headless services and PVC templates · Multi-pod applications and coordinating a consistent point · When database-native backup should be used instead of, or alongside, Velero
The half that counts. Restore semantics and what Velero will and will not overwrite, namespace mapping, existing-resource policy, resource modifiers, restore ordering, and then using the same mechanics deliberately to move workloads between clusters and clouds.
Topics: Restore semantics: what is created, skipped and patched · namespace-mappings and restoring into a different namespace · existingResourcePolicy and the update path · Resource modifiers: JSON patches applied during restore · restoreResourcePriorities and why ordering matters · Selective restore: single namespace, single resource type, label-scoped · Cluster migration: shared storage location, backup sync and cutover · Cross-provider migration and the storage class mapping problem · Restoring into a cluster with a different Kubernetes version
Turning Velero from a tool into an operational control. Monitoring and alerting on backup health, restore rehearsals on a cadence, immutability and ransomware considerations, RBAC and multi-tenancy, and the evidence pack that satisfies an auditor.
Topics: Prometheus metrics and alerts for failed and stale backups · Restore rehearsal cadence and scope, and rehearsing into a throwaway cluster · Object lock, versioning and immutability against ransomware · Backup encryption and key management · RBAC for Velero and multi-tenant backup responsibilities · Cost control: retention, storage class tiering and lifecycle rules · Upgrading Velero, plugin compatibility and CRD changes · Troubleshooting: PartiallyFailed backups, stuck restores, repository errors · Producing dated recovery evidence for audit
We rebuild the agenda around the tools you actually run.
Request a custom agendaInstall Velero against an object store using scoped identity rather than static keys, add a second region location, and verify before trusting it.
Design backup scope and retention for three workload tiers with different RPOs, then diagnose a deliberately PartiallyFailed backup from its logs.
Back up one StatefulSet with CSI snapshots, file-system backup and the data mover, and compare duration, storage cost and restore time.
Add pre and post backup hooks to a running database, take a backup under write load, and prove the restored copy is consistent.
Migrate a stateful application to a second cluster using a shared storage location, namespace mapping and a resource modifier for storage class remapping.
Destroy a production-like namespace including its volumes, restore it under timing, record the real RTO and RPO, and write the audit evidence.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.