<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <docs>https://blogs.law.harvard.edu/tech/rss</docs>
    <title>External-Secrets on Fuchsbau</title>
    <link>https://this-is-fine.io/tags/external-secrets/</link>
    <description>Recent content in External-Secrets on Fuchsbau</description>
    <image>
      <title>External-Secrets on Fuchsbau</title>
      <link>https://this-is-fine.io/tags/external-secrets/</link>
      <url>https://source.unsplash.com/2000x1322/?fox</url>
    </image>
    <ttl>1440</ttl>
    <generator>Hugo 0.125.4</generator>
    <language>de-DE</language>
    <lastBuildDate>Wed, 20 May 2026 22:26:11 UT</lastBuildDate>
    <atom:link href="https://this-is-fine.io/tags/external-secrets/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>VolSync, Volume Snapshots, and Restic Off-Site Backups</title>
      <link>https://this-is-fine.io/posts/20251121-volsync-restic-backups/</link>
      <pubDate>Fri, 21 Nov 2025 08:00:00 UT</pubDate>
      <dc:creator>ff0x</dc:creator>
      <guid>https://this-is-fine.io/posts/20251121-volsync-restic-backups/</guid>
      <description>Stateful apps need point-in-time copies and a copy off the cluster. The lab uses VolSync with the restic mover: Kubernetes creates a VolumeSnapshot, VolSync runs restic against it, and encrypted data lands in a remote repository. The restic URL and password live in Vault and reach the cluster through External Secrets.
VolSync sits in the middle: you already run the CSI snapshot controller and a storage class that supports snapshots (Rook-Ceph block volumes in the lab). VolSync watches a ReplicationSource, triggers on a schedule, and spins up a short-lived mover job. You get off-site copies without shelling into pods to run restic by hand.
</description>
      <category domain="https://this-is-fine.io/categories/infrastructure">Infrastructure</category>
      <content:encoded><![CDATA[Stateful apps need point-in-time copies and a copy off the cluster. The lab uses VolSync with the restic mover: Kubernetes creates a VolumeSnapshot, VolSync runs restic against it, and encrypted data lands in a remote repository. The restic URL and password live in Vault and reach the cluster through External Secrets.
VolSync sits in the middle: you already run the CSI snapshot controller and a storage class that supports snapshots (Rook-Ceph block volumes in the lab). VolSync watches a ReplicationSource, triggers on a schedule, and spins up a short-lived mover job. You get off-site copies without shelling into pods to run restic by hand.
Building blocks Software Role snapshot-controller CSI snapshot API VolSync ReplicationSource and movers (restic, rsync, &amp;hellip;) restic Encrypted, deduplicated backup format Rook-Ceph Block volumes and snapshot class Data path app PVC -&amp;gt; ReplicationSource (schedule, e.g. @daily) -&amp;gt; VolumeSnapshot (CSI) -&amp;gt; restic mover -&amp;gt; remote repository Retention and prune settings sit on the ReplicationSource. See VolSync restic usage.
GitOps pattern A common Flux app installs the VolSync operator once. Each app includes the shared template and sets dependsOn: volsync. Flux postBuild sets APP, capacity, schedule, and storage class — same mechanism as domains in the GitOps overview. Per-app repository paths append ${APP} at runtime so one leaked credential does not cover every volume.
Opt-in is intentional: not every Deployment needs a PVC backup. Stateless replicas and caches stay out unless you add the template. That keeps mover jobs and repository size predictable.
Example: opt in an app The bundle in k8s/templates/volsync/ ships a PVC, ExternalSecret, ReplicationSource, and ReplicationDestination.
1. Kustomize — include the template beside the workload:
# app/kustomization.yaml resources: - ../../../../../../templates/volsync - deployment.yaml 2. Flux — depend on the operator and substitute variables:
# ks.yaml (Flux Kustomization) spec: dependsOn: - name: volsync postBuild: substitute: APP: my-app VOLSYNC_SCHEDULE: &amp;#34;@daily&amp;#34; VOLSYNC_CAPACITY: 5Gi VOLSYNC_CACHE_CAPACITY: 5Gi VOLSYNC_STORAGECLASS: &amp;#34;${BLOCK_STORAGE_CLASS}&amp;#34; VOLSYNC_SNAPSHOTCLASS: &amp;#34;${BLOCK_STORAGE_CLASS}&amp;#34; 3. Deployment — mount the PVC the template creates (claimName must match APP):
volumes: - name: data persistentVolumeClaim: claimName: my-app Flux renders ${APP} on the ReplicationSource and sets repository: my-app-volsync-secret (restic settings from Vault via ExternalSecret):
apiVersion: volsync.backube/v1alpha1 kind: ReplicationSource metadata: name: &amp;#34;${APP}&amp;#34; spec: sourcePVC: &amp;#34;${APP}&amp;#34; trigger: schedule: &amp;#34;${VOLSYNC_SCHEDULE:-@weekly}&amp;#34; restic: copyMethod: Snapshot repository: &amp;#34;${APP}-volsync-secret&amp;#34; Full field list: ReplicationSource API.
Why snapshots? A snapshot avoids stopping the pod and works well with Ceph’s CSI driver. The mover reads consistent blocks from the snapshot volume instead of the live mount, which matters when the app keeps writing logs or database pages.
Restore is the mirror path: a ReplicationDestination pulls from restic into a target PVC when you need to recover or clone. The lab wraps that in task helpers; semantics follow the VolSync user guide.
]]></content:encoded>
    </item>
  </channel>
</rss>
