milestone 13 discrepancies: redact credentials from urls in logs, metrics and cli output

docs/how-to/back-up-and-restore.md

@@ -88,8 +88,8 @@ before writing to it.
 
 ## Restore over an existing database
 
-`import` refuses a database that already has content, so a plain `import` can
-never clobber a configured server by accident:
+`import` refuses a database that already holds configuration, so a plain
+`import` can never clobber a configured server by accident:
 
 ```sh
 nxdns import /tmp/nxdns-lab/backup.zon --data-dir /tmp/nxdns-lab/data
@@ -112,6 +112,13 @@ imported /tmp/nxdns-lab/backup.zon
 Stop the server first. `import` replaces the whole configuration underneath a
 process that has already read it, and a running server will not notice.
 
+What `--force` does to the client list is worth knowing before you restore an
+old backup. A client the backup does not name is removed, and its first-seen
+and last-seen go with it — restoring a month-old file drops the devices you
+named since. Devices the server discovered from traffic are kept, and a device
+the backup does name keeps the first-seen and last-seen the database already
+held, so a restore does not restamp your whole network as newly arrived.
+
 On a real install that is the systemd unit:
 
 ```sh
@@ -185,8 +192,9 @@ The data directory layout is in
 ## A backup before every upgrade
 
 There is no downgrade path. Schema migrations run forward automatically at
-startup and before `check`, `export` and `import`; nothing walks them back. Take
-an export before installing a new binary — see [upgrade](upgrade.md).
+startup and before `export` and `import`; nothing walks them back, and `nxdns
+check` does not run them at all. Take an export before installing a new binary —
+see [upgrade](upgrade.md).
 
 Every command on this page was executed on this host as written, except the
 `systemctl` block marked **Not verified on this host** above.