<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Velero - vo.rs</title><link>https://vo.rs/tags/velero/</link><description>Latest from the Velero desk at vo.rs.</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright><lastBuildDate>Tue, 24 Sep 2024 11:15:00 +0000</lastBuildDate><atom:link href="https://vo.rs/tags/velero/" rel="self" type="application/rss+xml"/><item><title>Velero: Backing Up Kubernetes, Not Just Volumes</title><link>https://vo.rs/story/velero-backing-up-kubernetes-not-just-volumes/</link><description>&lt;p&gt;The first time I lost a Kubernetes namespace to a fat-fingered &lt;code&gt;kubectl delete namespace&lt;/code&gt;, I discovered that my &amp;ldquo;backups&amp;rdquo; covered exactly the wrong half of the problem. The persistent volumes were sitting safely on a ZFS pool with nightly snapshots. The Deployments, Services, Ingresses, ConfigMaps, Secrets and the dozen other objects that actually described how those volumes were supposed to be used were gone, and rebuilding them from memory and half-remembered YAML took the better part of an evening. A PersistentVolume without the Deployment that mounts it is just an orphaned disk; the cluster state &lt;em&gt;is&lt;/em&gt; the application, and it needs backing up as deliberately as the data does.&lt;/p&gt;</description><pubDate>Tue, 24 Sep 2024 11:15:00 +0000</pubDate></item></channel></rss>