<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Ops on Margrop Blog</title>
    <link>https://blog.margrop.net/en/tag/ops/</link>
    <description>Recent content in Ops on Margrop Blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Mon, 13 Apr 2026 09:30:00 +0800</lastBuildDate>
    <atom:link href="https://blog.margrop.net/en/tag/ops/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>OpenClaw Backup Failure Investigation and Fix: From Two Broken Schedules to a Fully Restored Automation Pipeline</title>
      <link>https://blog.margrop.net/en/post/openclaw-backup-failure-investigation-and-fix/</link>
      <pubDate>Mon, 13 Apr 2026 09:30:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/openclaw-backup-failure-investigation-and-fix/</guid>
      <description>&lt;p&gt;This post is a full incident review, not because the failure was dramatic, but because it was a very typical automation problem.&lt;/p&gt;&#xA;&lt;p&gt;Two machines lost their automatic OpenClaw backups at the same time: a local macOS machine and a remote VPS. Manual runs worked on both sides, and the archives could still be synchronized to the NAS, but the scheduled jobs were unreliable. At first glance it looked like &amp;ldquo;the scheduler did not fire.&amp;rdquo; In reality, the root cause was spread across scheduling, permissions, locking, logging, and even the way I validated the schedule.&lt;/p&gt;&#xA;&lt;p&gt;That combination is what makes these incidents annoying: every individual piece looks almost fine, yet the full pipeline still fails.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Upgrading OpenClaw to 2026.3.23-2: A Real Compatibility Upgrade Playbook</title>
      <link>https://blog.margrop.net/en/post/openclaw-upgrade-to-2026-3-23-compatibility-playbook/</link>
      <pubDate>Tue, 24 Mar 2026 21:20:00 +0800</pubDate>
      <guid>https://blog.margrop.net/en/post/openclaw-upgrade-to-2026-3-23-compatibility-playbook/</guid>
      <description>&lt;p&gt;This post documents a real OpenClaw upgrade, not a laboratory demo. The goal was not simply to change a version string. The real goal was to move a small multi-node environment from &lt;code&gt;2026.3.8 / 2026.3.13&lt;/code&gt; to &lt;code&gt;2026.3.23-2&lt;/code&gt; while keeping message channels, external plugins, service startup behavior, and rollback paths under control.&lt;/p&gt;&#xA;&lt;p&gt;In practice, the most difficult part was not the OpenClaw core package. The hardest part was everything around it: plugin SDK compatibility, JIT cache reuse, mixed installation layouts, restricted outbound access on an edge node, and differences in bind mode that changed what health probes actually meant. If you do not identify those variables first, an upgrade can easily look successful while one or more production channels are already broken.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
