<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <title>Alexander Janzen — Notes from practice (English)</title>
  <subtitle>Short posts on topics that come up in operation: addressing, backups, access. All from hands-on experience — and without details that are nobody else's business.</subtitle>
  <link rel="alternate" type="text/html" hreflang="en" href="https://alexanderjanzen.de/en/blog"/>
  <link rel="alternate" type="text/html" hreflang="de" href="https://alexanderjanzen.de/blog"/>
  <link rel="alternate" type="application/atom+xml" hreflang="de" href="https://alexanderjanzen.de/feed.xml"/>
  <link rel="self" type="application/atom+xml" href="https://alexanderjanzen.de/en/feed.xml"/>
  <id>https://alexanderjanzen.de/en/blog</id>
  <updated>2026-09-22T09:00:00+02:00</updated>
  <author><name>Alexander Janzen</name><uri>https://alexanderjanzen.de/</uri></author>
  <rights>© 2026 Alexander Janzen</rights>
  <entry>
    <title>Why the automatic range sits behind every fixed place</title>
    <link rel="alternate" type="text/html" href="https://alexanderjanzen.de/en/blog#adressplan"/>
    <id>https://alexanderjanzen.de/en/blog#adressplan</id>
    <published>2026-09-22T09:00:00+02:00</published>
    <updated>2026-09-22T09:00:00+02:00</updated>
    <author><name>Alexander Janzen</name></author>
    <summary type="text">A device without a fixed address once took a server's address. The service was unreachable for a few minutes, and the cause was unspectacular: the range used for automatic addressing contained addresses I had assigned by hand.</summary>
    <content type="html">&lt;p&gt;A device without a fixed address once took a server's address. The service was unreachable for a few minutes, and the cause was unspectacular: the range used for automatic addressing contained addresses I had assigned by hand.&lt;/p&gt;&lt;p&gt;The solution was not new technology but an order — every fixed place first, the automatic range behind it. Since then a device from the automatic range cannot take an address that is already in use. In addition, every address change is followed by checking each device individually.&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>A backup without a restore test is a hope</title>
    <link rel="alternate" type="text/html" href="https://alexanderjanzen.de/en/blog#sicherung"/>
    <id>https://alexanderjanzen.de/en/blog#sicherung</id>
    <published>2026-09-08T09:00:00+02:00</published>
    <updated>2026-09-08T09:00:00+02:00</updated>
    <author><name>Alexander Janzen</name></author>
    <summary type="text">A backup run that finishes without an error message says nothing about whether the data really comes back when it matters. That experience is why the goal here is not the backup but the successful restore.</summary>
    <content type="html">&lt;p&gt;A backup run that finishes without an error message says nothing about whether the data really comes back when it matters. That experience is why the goal here is not the backup but the successful restore.&lt;/p&gt;&lt;p&gt;So there is a second storage target, and at fixed intervals a restore is genuinely rehearsed: fetch a file back, restore a machine, tick off the result. What has never been tested does not count as a backup.&lt;/p&gt;</content>
  </entry>
  <entry>
    <title>Remote access without open ports</title>
    <link rel="alternate" type="text/html" href="https://alexanderjanzen.de/en/blog#fernzugang"/>
    <id>https://alexanderjanzen.de/en/blog#fernzugang</id>
    <published>2026-08-25T09:00:00+02:00</published>
    <updated>2026-08-25T09:00:00+02:00</updated>
    <author><name>Alexander Janzen</name></author>
    <summary type="text">Nothing on the router is reachable from outside. The path runs through a tunnel with an identity check and a second factor in front — no interface appears at all until the sign-in is complete.</summary>
    <content type="html">&lt;p&gt;Nothing on the router is reachable from outside. The path runs through a tunnel with an identity check and a second factor in front — no interface appears at all until the sign-in is complete.&lt;/p&gt;&lt;p&gt;The actual proof was a hardening test: after rebuilding access I requested every published address without signing in. All of them answered "access denied" and not a single interface was visible. Also verified: after several failed attempts the lock kicks in and raises an alert — "should be protected" is not proof.&lt;/p&gt;</content>
  </entry>
</feed>
