# Device Resilience: Analysis and Strategy

## How to Use This Document

This document analyses the problem of keeping your data, credentials, configuration, and access safe across phones, laptops, and servers, recoverable when devices break or are stolen, and coherent across multiple devices during daily use. It establishes principles, requirements, and a phased plan.

It does not recommend specific tools (that builds on these requirements), nor does it cover day-to-day operational security (phishing, screen locks, safe browsing).

It assumes a technically skilled reader comfortable with encryption, version control, and self-hosting, who may be part of a household with shared and private data.

**Reading paths.** First time: read sequentially. Choosing tools: use the user stories (section 12) as a requirements checklist, informed by the technical detail in sections 7-10. After a device is stolen: go directly to recovery procedures (section 16). Building your setup: sections 13-15 in order. Ongoing maintenance: Phase 6 of section 15.

---

# Part I: Understanding the Problem

## 1. The Problem

You own several devices. Each holds some combination of data, configuration, credentials, and state. You face two interrelated problems.

**The loss problem.** Any device can break, be stolen, be seized, or become corrupted. When this happens, you suffer permanent data loss, downtime, security exposure, tedious recovery labour, or cascading failures where the recovery infrastructure was on the thing that died.

**The coherence problem.** You use multiple devices daily. You want certain things to be the same or available across them: passwords, documents, dev environment, contacts. You want changes to propagate. You want some things to work offline. And you want none of this to degrade the devices you're using.

These problems interact. Sync partly solves recovery (your data is already on another device) but creates risk (corruption or deletion propagates everywhere). A good system addresses both coherently.

**Your constraints.** You are one person, possibly part of a household. This is not your job. Whatever you build must run itself after initial setup, tolerate weeks of neglect, and not consume your weekends. You value privacy and self-sovereignty but will accept pragmatic compromises where the self-hosted alternative is dramatically worse or more fragile.

**Diminishing returns.** Each phase of this system delivers standalone value. Stop at whichever phase covers the risks you care about.

---

## 2. What You're Protecting

People consistently undercount what lives on their devices. Read this inventory against your own situation.

### 2.1 Data

- **Documents and working files** — writing, spreadsheets, notes, project files, annotated PDFs
- **Code and repositories** — source code, scripts, local branches with unpushed work
- **Photos and videos** — often irreplaceable, often large
- **Music, audiobooks, other media** — downloaded/purchased content
- **Financial records** — tax documents, receipts, invoices, statements
- **Health and fitness data** — workout logs, medical records, tracking data
- **Bookmarks, read-later lists, annotations** — curated references built over time
- **Email archives** — a communication channel, document archive, legal record, and identity anchor (password resets). Worth backing up privately across providers; losing an email provider cascades into losing password resets, which cascades further

### 2.2 Credentials

- **Passwords** — for every service
- **TOTP/2FA tokens** — the second factor that becomes a trap if lost
- **SSH keys, GPG keys** — server access, signing, encryption
- **API keys, tokens, certificates** — integrations, VPN, self-signed CAs
- **Recovery codes** — backup for 2FA; often printed once and lost
- **Hardware key registrations** — which FIDO2 keys are registered where
- **Encryption keys and passphrases** — for backups, vaults, encrypted volumes; these protect everything else (see section 10)
- **Automation credentials** — CI/CD tokens, home automation API keys, webhook secrets, cron job credentials; invisible until they break

### 2.3 Configuration

- **OS-level settings** — display, keyboard, accessibility, power, network
- **Shell, terminal, editor, IDE** — aliases, functions, keybindings, extensions, snippets, themes
- **Application preferences** — every app tweaked from defaults
- **Browser state** — bookmarks, extensions, saved logins; extension-specific data is often not covered by browser sync
- **Email configuration** — accounts, filters, signatures, folder structure
- **Dev toolchain** — runtimes, package managers, build tools, linters, formatters, pinned versions
- **Server configuration** — services, networking, firewall, cron, reverse proxy, DNS
- **Container and VM definitions** — composition, volumes, mounts; sometimes accumulate meaningful state treated as disposable but not
- **Network configuration** — Wi-Fi credentials, VPN profiles, static IPs
- **Automation definitions** — CI/CD pipelines, home automation, scheduled tasks, webhooks; spread across many systems

### 2.4 State

- **Messaging history** — Signal, WhatsApp, Matrix, IRC, Slack
- **Browser sessions** — open tabs, reading position, cookies
- **Application state** — open workflows, drafts
- **Notification state** — what's read, pending, triaged
- **Game saves**

### 2.5 Access

- **Device enrolment** — trusted device for 2FA push, banking apps, device-bound sessions
- **Paired peripherals** — Bluetooth, printers, hardware tokens
- **Licences and activations** — software tied to a device
- **App purchases and subscriptions** — tied to an app store account
- **Carrier/SIM/eSIM** — phone number; increasingly an identity anchor
- **Active sessions** — currently logged-in services; must be revoked after theft

### 2.6 Infrastructure

- **Domain registrar and DNS** — arguably your most critical single point of failure if you own a domain for email or services. Expired domain or locked registrar cascades into loss of email, then password resets, then everything. Deserves Tier 0 treatment.
- **Self-hosted services** — if sync, backup, or authentication depend on a server you run, that server is a prerequisite for everything else. If it's your only sync or backup target, its loss cascades to all devices.
- **NAS or local network storage** — offsite relative to the device but not the house. Handles "laptop died" but not "house fire."
- **Power and physical setup** — UPS, clean shutdown on power loss, auto-restart, whether backup drives are always connected (ransomware risk) or only during backup windows

### 2.7 Recovery Prerequisites

These aren't on your devices, but you need them during recovery.

- **Identity documents** — government ID, proof of address, account numbers. Needed to prove who you are to carriers, banks, and cloud providers. Digital copies in your vault alongside physical originals speed up recovery, especially abroad.
- **Account inventory** — do you know what accounts you have, what's logged in on each device, what's device-bound? Your vault covers most, but people commonly have accounts not in it, services via "Sign in with Google/Apple" that don't appear as entries, and forgotten OAuth grants. To build one: search email for "welcome," "verify," "confirm your account"; review OAuth connections in Google/Apple/GitHub settings; review app permissions on your phone.

---

## 3. Categorising What You Protect

Each item in section 2 should be evaluated along three dimensions. The right answer differs per category; applying the same approach to everything is one of the most common mistakes.

### 3.1 Availability

| Mode | Meaning | Examples |
|------|---------|---------|
| Synced | Live on multiple devices; changes propagate | Passwords, contacts, calendar, working docs, notes |
| Accessible | Available on demand, not necessarily local | Photo archive, old financial records, email archive |
| Recoverable | Not needed daily across devices; must survive loss | Full photo archive, old projects, database dumps |
| Archived | Might need someday; indefinite cheap storage | Completed projects, old tax years |
| Disposable | Acceptable to lose | App caches, browser sessions, notification state |

The difference between "recoverable" and "archived" matters: backup has a retention window and prunes old snapshots. Without a separate archival tier, you can delete something, have it age out of all snapshots, and want it six months later.

### 3.2 Offline Requirement

| Level | Meaning | Examples |
|-------|---------|---------|
| Must | Full function, no network | Passwords, 2FA, contacts, calendar, working docs, dev toolchain, local git |
| Should | Degraded mode acceptable | Notes, reference docs, music |
| Online fine | Only used when connected | Email fetch, server access, photo archive browsing |

### 3.3 Performance Sensitivity

| Level | Meaning | Examples |
|-------|---------|---------|
| Latency-critical | Felt during active use | Vault lookup, file open/save, editor, compilation, shell startup |
| Throughput-sensitive | Bandwidth/IO matters; seconds of latency OK | Photo upload, file sync, backup, large git ops |
| Background-tolerant | Can run slowly | Nightly backups, offsite replication, media sync |

---

## 4. Threat Model

Not all loss scenarios are equal. Each invalidates different parts of your safety net.

### 4.1 Scenarios

**Hardware failure.** SSD dies, screen shatters, disk fails. Pure recovery; no security concern. Most common device-level failure.

**Software failure.** Botched OS update, filesystem corruption, failed upgrade. Hardware is fine but data is damaged. Recovery is often "wipe and restore."

**Accidental deletion.** Wrong file deleted, document overwritten, destructive command run. Most common cause of data loss in practice. Sync propagates the mistake; point-in-time backup is the protection.

**Theft or loss.** Recovery plus security response. Time pressure: security response (wipe, session revocation, credential rotation) before recovery.

**Ransomware or malware.** Device compromised; local data encrypted or exfiltrated. If the device has credentials for sync or backup infrastructure, those may be compromised too.

**Cloud account lockout.** Google, Apple, or other cloud account suspended, hacked, or locked by automated policy. You lose everything stored there.

**SIM swap.** Attacker convinces your carrier to transfer your number, receiving your SMS 2FA codes and intercepting password resets. Distinct from theft: you still have your phone. This is why SMS is the weakest second factor.

**House fire, flood, or burglary.** Every device at your location gone, including NAS and cold backup if in the same building.

**Provider shutdown.** VPS host, backup provider, or critical tool ceases to exist or has a prolonged outage.

**Government seizure.** Devices forensically examined. Full-disk encryption protects at rest. Compelled decryption varies by jurisdiction.

**Incapacitation.** You can't manage your systems. Tests bus factor.

### 4.2 What Each Scenario Invalidates

| Scenario | Local data | Sync copies | Online backup | Offline/cold backup | Security exposure |
|----------|-----------|-------------|---------------|--------------------|--------------------|
| Hardware failure | Lost | Safe | Safe | Safe | None |
| Software failure | Damaged | Safe | Safe | Safe | None |
| Accidental deletion | Lost (that item) | At risk (propagates) | Safe (if retained) | Safe | None |
| Theft/loss | Lost | Safe | Safe | Safe | High |
| Ransomware | Compromised | At risk | At risk | Safe | High |
| Cloud lockout | Safe | At risk (if vendor) | At risk (if same vendor) | Safe | Low |
| SIM swap | Safe | Safe | Safe | Safe | High (SMS 2FA) |
| House fire | Lost | At risk (if on-premises) | Safe (if off-premises) | At risk (if on-premises) | None |
| Provider shutdown | Safe | At risk (if that provider) | At risk (if same provider) | Safe | Low |
| Seizure | Taken | Safe (if elsewhere) | At risk (if compelled) | At risk (if found) | Full |
| Incapacitation | Inaccessible | Inaccessible | Inaccessible | Inaccessible | None |

Offline/cold backup is the only column that is "Safe" across every adversarial scenario. Sync is vulnerable to accidental deletion, ransomware, and on-premises disasters. Online backup is vulnerable to ransomware (cached credentials) and provider failures. No single layer covers everything; they are complementary.

---

## 5. Household Considerations

If you live with other people, the problem expands beyond "my devices, my data."

### 5.1 Common Scenarios

**Shared data.** Photo libraries, household documents, shared lists, shared calendar.

**Private data on shared infrastructure.** You share a NAS, server, or network, but each person's passwords, files, and messages stay private.

**Multiple people needing resilience.** Your partner's phone can also be stolen. Shared infrastructure can serve the household, but each person needs their own credentials, encryption, and recovery path.

**Shared credentials.** Streaming services, utilities, joint bank accounts. Should live in shared vault entries.

**Children's devices.** If applicable: different trust model, managed devices, different data sensitivity, parental access.

**Selective external sharing.** Sharing specific files or folders with people outside the household (a collaborator, an accountant) without exposing your sync infrastructure.

### 5.2 Architectural Implications

Your setup needs per-person private spaces, shared spaces with controlled access, cross-ecosystem compatibility (one person on iOS, another on Android, mixed desktop OSes), and bus factor coverage (if you're incapacitated, your partner can access shared data and keep infrastructure running at a basic level). Solutions that only work within a single vendor ecosystem become harder to justify when the household is mixed-platform.

---

# Part II: Strategy

This part covers the principles and technical knowledge you need before choosing tools or planning your implementation. Section 6 presents the high-level strategy. Sections 7-9 go deeper on the three main technical domains (sync, backup, performance). Section 10 addresses encryption key management, a cross-cutting concern that builds on sections 7-9. Section 11 identifies constraints with no clean solution.

## 6. Core Principles

These are distilled from what experienced people converge on after doing this more than once.

### 6.1 Foundational

**Separate data from compute.** The device is disposable; the data is durable. If your server dies but your data lives elsewhere, you rebuild.

**Sync is not backup.** Sync propagates deletions and corruption. Backup preserves point-in-time snapshots. You need both. Confusing them is the most common and most costly mistake in this space.

**The 3-2-1 rule.** Three copies of important data, two media types, one offsite.

**Offline-first for critical tools.** Vault, 2FA, contacts, calendar, and working documents must work without a network. If the "local" client is really a cache in front of a remote API, you will be caught at the wrong moment.

**Start from Tier 0 and work outward.** Secure your ability to authenticate and communicate first, then protect irreplaceable data, then build convenience. This means you're protected against the worst scenario first, and you can stop at any point.

### 6.2 Recovery Tiers

Not everything needs to be recoverable instantly.

**Tier 0 — Immediate (minutes).** Authenticate, communicate, not be locked out. Vault from another device, 2FA recovery independent of the dead device, ability to call or message someone. If you can't pass Tier 0, everything else stalls.

**Tier 0.5 — Borrowed device (minutes to hours).** Nothing but a borrowed browser and your memory. The sequence: memorised vault master password → vault 2FA via a method independent of all your devices (recovery code from physical printout, or hardware key on your person) → vault → email and critical services. If any step fails, you're stuck. Test it. Note: if the only way to get your vault's 2FA recovery codes is from inside the vault, you have a deadlock (see section 10).

**Tier 1 — Same day (hours).** Primary work and life capability. Email, files, code, servers, urgent tasks.

**Tier 2 — This week (days).** Full equivalent state. Right shell, editor, apps, settings, browser.

**Tier 3 — Acceptable loss.** Things you've consciously decided might not survive. Name them explicitly so you don't discover them during a crisis.

**Tier C — Catastrophic (offline/cold).** House burned down, accounts locked, server compromised. Starting from a physical backup in a safe or at a relative's house.

### 6.3 Practical

**Automate, then verify.** Manual backups stop after three weeks. Untested automated backups are false security.

**Design and test the recovery sequence.** Each step depends on the previous one. A capability that works in isolation can fail if its prerequisite isn't met. Walk through it on paper; try it for real at least once.

**Accept phone vendor lock-in for app restore.** Use vendor backup (iCloud, Google) for app installation and settings. Layer self-hosted solutions for the data you control. Privacy-focused OSes that forego vendor backup sacrifice app-restore convenience; this is a conscious tradeoff.

**Three tiers of data handling.** Sync working data (available everywhere, offline-capable). Back up everything important (point-in-time recovery). Archive the rest (long-term, cheap, indefinite). This keeps daily sync fast and backup manageable.

**Exclude the reproducible.** `node_modules`, `.venv`, `target/`, `build/` from sync and backup. Biggest performance and storage win.

**Physical backup of critical key material.** Recovery codes, encryption passphrases, emergency instructions: printed, sealed, off-site. Resilient to every digital failure mode. Your vault's own 2FA recovery must be accessible without the vault.

**A spare device in a drawer.** Cheap old phone, secondary laptop; anything that gets you to Tier 1 without waiting for delivery.

**The runbook is the most underrated piece.** A recovery document, accessible from multiple independent paths, written when calm, followed when stressed.

---

## 7. Sync

### 7.1 Topologies

**Hub-and-spoke.** All devices sync to/from a central server. Simpler conflict resolution. Single point of failure unless redundant.

**Peer-to-peer.** Devices sync directly. No server needed; works on LAN without internet. Harder conflict resolution; needs overlapping online time or relay infrastructure.

**Hybrid.** Peer-to-peer with an always-on peer (server or NAS) as relay/cache. LAN speed locally, relay remotely, always-available copy. Where experienced setups converge.

### 7.2 Conflict Resolution

**Last-write-wins.** Simple, destructive. Acceptable for contacts and settings; dangerous for documents.

**File-level conflict copies.** Conflicting edits produce a duplicate you resolve manually. Annoying but safe.

**CRDTs / operational transforms.** Semantic merging. What collaborative editors do. Very few self-hosted tools offer this.

**Git-based merging.** For code and plain text, well understood with free version history. Natural for anything in git; worth considering for other plain-text data.

For most personal use: git for text, conflict copies for binary/opaque files. Know which strategy your tools use.

### 7.3 What to Sync vs. Not

Sync has costs: bandwidth, storage, CPU, battery, conflict complexity. Apply the availability dimension from section 3: does this need to be synced, or just accessible on demand, or just recoverable?

Commonly over-synced: full photo libraries to every device, entire home directories, large media, build artefacts. Commonly under-synced: notes, working documents, dotfiles, contacts, calendars.

### 7.4 Offline-First Design

For anything that must work offline (section 3.2), the architecture should be: full local copy that works independently, with sync as an enhancement. If the sync server dies, the local copy is fully functional.

Test: turn off your network. Can you still use the thing?

---

## 8. Backup, Archival, and Retention

### 8.1 Why Sync Is Not Backup

Sync keeps copies consistent; it propagates deletions and corruption everywhere. Backup keeps copies *historical*: point-in-time snapshots. Accidental deletion, the most common data loss, is exactly where sync makes things worse and backup makes things better.

### 8.2 Archival as a Distinct Tier

Sync wastes resources on data you're not using. Backup's retention window prunes old snapshots. Archival is indefinite, cheap, low-access storage for data you're done with but might want. Without it, deleted data eventually ages out of every snapshot.

### 8.3 Retention Policies

Decide per data category: how many snapshots to keep and for how long (e.g., daily for 30 days, weekly for 6 months, monthly for 2 years), when synced-then-deleted data is truly gone, and what moves to archival. No policy defaults to "keep everything forever" until disk fills.

**Worth keeping indefinitely.** Irreplaceable personal media. Financial and legal records (7 years is a common minimum; verify yours). Key personal documents. Everything else is a cost-vs-value decision.

### 8.4 Storage Growth

Photos and videos accumulate. Snapshots multiply. Plan for growth at setup time: retention policies, archival tier, periodic pruning. Otherwise costs creep up and you never prune because you're afraid to.

### 8.5 Ransomware-Resistant Backup

If a compromised device has credentials for your backup, the backup is at risk (see section 4.2). At least one target should be unreachable from any device that could be compromised: append-only storage, offline media, or a pull-based architecture where the backup system reaches into production rather than production pushing out.

### 8.6 Initial Seeding

Hundreds of gigabytes plus residential upload speeds means the first full remote backup may take weeks. Seed locally or via physical media and let offsite replication happen in the background. Only the initial seed is slow; incremental backups are fast.

### 8.7 Tool Migration and Format Lock-In

You will change tools eventually. Projects get abandoned, better options appear, needs evolve.

What makes migration painful: proprietary formats unreadable without the original tool, databases that don't export cleanly, history and metadata lost in translation. What makes it manageable: open or documented formats, standard protocols (CalDAV, CardDAV, IMAP), data stored as files on disk where possible, the ability to run old and new in parallel during transition.

This doesn't mean refusing anything proprietary. It means preferring open formats when quality is comparable, and understanding exit cost before committing.

---

## 9. Performance

### 9.1 Laptops and Desktops

Badly behaved sync and backup causes CPU spikes during active work, I/O contention slowing builds and editors, memory pressure, network saturation, and battery drain. Good tools throttle CPU and bandwidth, schedule intensive work for idle periods, exclude unneeded directories, and use filesystem events instead of polling.

Build artefact exclusion is the single most impactful fix. `node_modules`, `target/`, `.venv`, `build/` can contain hundreds of thousands of reproducible files causing sync churn, slow backups, and storage bloat.

### 9.2 Phones

Battery is the constraint. Good mobile sync batches uploads, defaults to Wi-Fi only, and respects OS battery optimisation. Photo upload is the biggest consumer; default to Wi-Fi and charging only.

### 9.3 Servers

Avoid competing with production. Schedule for low-traffic periods, throttle I/O, use non-locking database backups. On cloud providers with metered egress, aggressive offsite backup can be unexpectedly expensive.

### 9.4 Sync and Backup Interaction

Both consume I/O and watch for file changes. Running both aggressively at once thrashes a laptop disk. Stagger or configure to avoid interference. Performance tuning (exclusions, scheduling, throttling) should be part of initial setup.

---

## 10. Encryption and Key Management

This section builds on sections 7-9. Sync, backup, vault, and disk encryption all protect your data, but that protection is only as recoverable as the keys that unlock it. This is where the deadliest circular dependencies hide.

### 10.1 Common Deadlocks

Your backup encryption key is in your vault, and your vault is in the encrypted backup. Your vault needs 2FA, and your 2FA was on the dead phone. Your GPG key encrypts your password store, and the GPG passphrase is in the password store.

### 10.2 What Needs an Independent Recovery Path

Each of the following must be recoverable *without* the thing it protects:

- **Vault master password** — memorised; root of the entire recovery chain
- **Vault 2FA recovery** — stored *outside* the vault (physical printout, hardware key on your person); if the only path to your vault's 2FA recovery is through the vault, you have a deadlock
- **Backup encryption passphrase** — in your vault (accessible via the above two items) *and* on your physical printout as a second path
- **Disk encryption recovery key** — in vault and/or physical printout
- **2FA recovery codes for critical services** — email, domain registrar, cloud accounts; in vault
- **Any key other encrypted things depend on** — GPG master key, CA private key

The dependency chain should be: memorised master password → vault (via web, 2FA from physical printout or hardware key) → everything else. No cycles.

### 10.3 Storage Options for Key Material

**Memorised.** Vault master password, possibly one or two other passphrases. Limit to 2-3 items.

**Physical printout.** Sealed envelope in a fireproof safe, trusted person's home, or safety deposit box. Resilient to all digital failure modes; vulnerable to physical access.

**Trusted person.** Sealed envelope with partner, family member, or solicitor. Covers incapacitation.

**Split secret.** Key material split across locations or people (Shamir's Secret Sharing). Resilient and secure but complex; only justified for truly critical keys.

### 10.4 The Test

Draw the dependency graph. For each encrypted thing, trace: "starting from only a borrowed browser and my memory, can I reach this?" If not, fix it before you need it.

---

## 11. Constraints and Unsolved Problems

These constrain your design and set realistic expectations. Worth knowing before selecting tools.

**Messaging history is structurally fragile.** E2EE messengers make server-side backup impossible by design. Device-backup mechanisms are afterthoughts. Plan for partial or total loss.

**Phone app data is a walled garden.** Sandboxed and not user-accessible. Vendor backup handles it opaquely; self-hosted backup can only cover what apps expose. Privacy-focused OSes sacrifice this further.

**Device-bound identity is an increasing trap.** Banking apps, government ID apps, 2FA push. No general backup for "this device is trusted." Mitigate by registering multiple devices and documenting re-enrolment per service.

**Health data is ecosystem-locked.** Exportable but no self-hosted equivalent that apps write to.

**Cold credential backup is a security-recoverability tension.** More recoverable means more attackable. You choose a point on the curve.

**Dev environment sync is partially unsolvable.** Sync the declarative description (configs, package lists, lockfiles); replay on each machine for equivalent state, not identical bits. Subtle toolchain or OS differences can still cause divergence.

**File sync on Linux desktops lacks a polished answer.** No vendor-integrated solution comparable to iCloud Drive or OneDrive.

**Large binary files defeat sync.** VMs, database dumps, video projects break deduplication and create huge payloads. Need separate handling.

**Email backup across providers is fiddly.** IMAP is standard but each provider has quirks.

**Self-hosted infrastructure can be a single point of failure.** If one server runs sync, backup, and monitoring, its death cascades everywhere. Distribute roles or ensure devices function independently during downtime.

**Accidental deletion is the most common data loss and the hardest to prevent.** Access controls and encryption don't help. Point-in-time backup with sufficient retention is the only protection. Sync makes it worse by propagating the mistake.

---

# Part III: Requirements

## 12. User Stories

These are the requirements your system should satisfy. The availability, offline, and performance annotations use the dimensions from section 3; use them during tool selection. Stories without annotations are process or security concerns.

### 12.1 Phones

| ID | Story | Avail. | Offline | Perf. |
|----|-------|--------|---------|-------|
| P1 | When my phone is lost, I can make calls, send messages, and access critical accounts from a replacement within hours | — | — | — |
| P2 | My photos and videos are automatically copied to storage I control | Recoverable | Online fine | Background |
| P3 | Contacts, calendars, and tasks synced and accessible from other devices immediately | Synced | Must | Latency |
| P4 | 2FA tokens recoverable from another device or secure backup | Synced | Must | Latency |
| P5 | Password vault accessible from any remaining device | Synced | Must | Latency |
| P6 | A stolen phone with locked screen cannot access my accounts, data, or identity | — | — | — |
| P7 | I can remotely wipe or lock a stolen phone | — | Online fine | — |
| P8 | Apps, layout, and settings restorable without hours of manual work | Recoverable | Online fine | Background |
| P9 | Messaging history recoverable for important conversations | Recoverable | Online fine | Background |
| P10 | Health and fitness data survives device loss | Recoverable | Online fine | Background |
| P11 | Device-bound access re-establishable; identity documents accessible | — | — | — |
| P12 | Phone number transferrable quickly; critical accounts don't depend on SMS 2FA | — | — | — |
| P13 | Notes synced across devices and work offline | Synced | Must | Latency |
| P14 | After theft, sessions revocable and credentials rotatable using a pre-written checklist | — | Online fine | — |
| P15 | During the gap, key people can reach me via a pre-agreed alternative | — | — | — |

### 12.2 Desktops and Laptops

| ID | Story | Avail. | Offline | Perf. |
|----|-------|--------|---------|-------|
| D1 | Usable working state within hours; full equivalent within a day or two | — | — | — |
| D2 | Documents and working files synced (offline-capable) and backed up with point-in-time recovery | Synced | Must | Throughput |
| D3 | Dev environment reproducible from a declarative description | Recoverable | Online fine | Background |
| D4 | Dev environment broadly consistent across machines via templated config | Synced | Should | Latency |
| D5 | Cryptographic keys and credentials recoverable from secure backup | Recoverable | Should | Latency |
| D6 | Browser state synced across devices | Synced | Should | Latency |
| D7 | A stolen laptop leaks no meaningful data | — | — | — |
| D8 | Email, calendar, and contacts not stored only on this machine | Synced | Should | Latency |
| D9 | All code pushed to a remote; mechanism to avoid unpushed work being the sole copy | Synced | Must | Throughput |
| D10 | OS settings broadly restorable without remembering each one | Recoverable | Online fine | Background |
| D11 | Recovery doesn't depend on another device that might also be unavailable | — | — | — |
| D12 | Sync and backup don't degrade performance during active use | — | — | Latency |
| D13 | Email archive backed up privately, across multiple providers | Recoverable | Online fine | Background |
| D14 | Pre-written post-theft checklist for sessions, keys, and credentials | — | Online fine | — |
| D15 | Critical work possible from a secondary device during downtime | — | — | — |

### 12.3 Servers

| ID | Story | Avail. | Offline | Perf. |
|----|-------|--------|---------|-------|
| S1 | Rebuild from version-controlled configuration | Recoverable | Online fine | Background |
| S2 | Application data backed up regularly with verified restores | Recoverable | Online fine | Throughput |
| S3 | Secrets not in plaintext in repos, but recoverable | Recoverable | Should | Latency |
| S4 | DNS, networking, and firewall codified | Recoverable | Online fine | Background |
| S5 | Aware of downtime or degradation before it becomes a crisis | — | Online fine | Latency |
| S6 | Rebuild process documented, tested, with known duration | — | — | — |
| S7 | Can migrate providers without heroic effort | — | — | — |
| S8 | Backup and sync don't compete with production workloads | — | — | Throughput |
| S9 | Domain registrar secured, documented, accessible in emergency; renewal tracked and alerted | — | — | — |
| S10 | Home self-hosting handles power outages gracefully | — | — | — |
| S11 | Automation credentials documented and recoverable | Recoverable | Online fine | Background |
| S12 | If this server is the sync/backup target, other devices degrade gracefully and resume automatically | — | — | — |

### 12.4 Household

| ID | Story |
|----|-------|
| H1 | Shared household data accessible to relevant members |
| H2 | Each person's private data stays private, even on shared infrastructure |
| H3 | Shared credentials managed through a shared vault |
| H4 | System works across different ecosystems within the household |
| H5 | If I'm incapacitated, my partner can access shared data and keep infrastructure running |
| H6 | Each member has their own independent recovery path |

### 12.5 Cross-Cutting

| ID | Story |
|----|-------|
| X1 | All backups and synced data encrypted in transit and at rest |
| X2 | Restores periodically verified, ideally with some automation |
| X3 | Backup and sync infrastructure documented, reproducible, not a single point of failure |
| X4 | Recovery runbook per device class, multiply accessible, reviewed annually, updated after changes |
| X5 | Not wholly dependent on any single vendor for recovery |
| X6 | Automated, tolerant of neglect, alerts on failure rather than silently rotting |
| X7 | Offline cold backup for catastrophic scenarios, unreachable from networked devices, refreshed periodically |
| X8 | Trusted person can access critical things if I'm incapacitated |
| X9 | Total cost reasonable with understood growth trajectory |
| X10 | Incrementally adoptable; each phase standalone |
| X11 | Graceful degradation; broken parts don't cascade |
| X12 | Sync conflicts handled predictably |
| X13 | Works on actual network conditions including slow, intermittent, or metered |
| X14 | Encryption keys backed up outside the things they protect; no deadlocks |
| X15 | Data in open or exportable formats; tools changeable without data loss |
| X16 | Monitoring independent of the system being monitored |
| X17 | Preference for strong privacy/security jurisdictions and solutions, all else equal |
| X18 | Retention policies per data category balancing preservation against growth |
| X19 | At least one backup unreachable from any compromisable device |
| X20 | Account inventory maintained for post-theft response |
| X21 | Spare device available to bridge the gap to Tier 1 |
| X22 | Backups organised for finding a specific item under stress |
| X23 | Selective sharing with external collaborators without exposing sync infrastructure |

---

# Part IV: Implementation

## 13. Approach by Device Class

### 13.1 Phones

Use vendor backup for app installation and settings. Layer self-hosted solutions for photos, contacts, calendar, passwords, and 2FA. This gives fast Tier 1 recovery via vendor restore plus data sovereignty for what matters.

Ensure multiple paths to your second factor: hardware keys for critical accounts, 2FA app with encrypted backup, recovery codes in vault. This is the highest-leverage Tier 0 action.

Keep your phone number transferrable. Pre-agree a communication fallback for the gap. Default large uploads to Wi-Fi and charging only.

### 13.2 Desktops and Laptops

Sync working directories for daily multi-device access. Back up broadly for point-in-time recovery. Archive completed work to cheap long-term storage.

Capture your environment declaratively: packages, shell config, editor settings in version control. On a new machine, clone and run a setup script. Handle per-machine differences with templating, not separate branches.

Treat your vault as source of truth for credentials; machines are caches. Exclude build artefacts from sync and backup. Configure sync and backup to reduce activity during active use and catch up at idle. Pull email via IMAP into a local archive.

Ensure your phone or a browser can handle critical workflows (SSH, email, document editing) during primary machine downtime.

### 13.3 Servers

Rebuild from config; back up data independently. Keep configuration, containers, DNS, and firewall rules in version control. Monitor from an external vantage point so a dead server doesn't silently take monitoring with it.

Secure your domain registrar account, track renewal, alert on expiry, keep DNS in version control. If self-hosting at home: UPS, clean shutdown, verified auto-restart, and a conscious decision about backup drive connection policy.

Ensure at least one backup target the server cannot overwrite. Avoid concentrating sync, backup, monitoring, and production on one server; if impractical, ensure other devices function independently during downtime.

### 13.4 Households

Shared infrastructure with per-person private spaces: one NAS or server, per-person encryption and access controls, shared folders for shared data. Choose solutions that work across the household's device mix.

Shared credentials in shared vault entries. Written bus-factor instructions a non-technical partner can follow, stored physically and in a vault they can access.

---

## 14. Common Mistakes

These are the most frequent sources of regret. Read them before starting the phased plan.

**Over-engineering.** The number one regret among skilled enthusiasts. Maintenance burden compounds. Self-host what you genuinely benefit from controlling; use something boring and reliable for the rest.

**Not testing restores.** The first real restore reveals corruption, incompleteness, or dependencies you didn't know about.

**Circular dependencies.** Vault backup on a server you need the vault to access. Vault 2FA recovery inside the vault. Draw the graph; eliminate cycles.

**Treating all data equally.** Photos are irreplaceable; OS settings are an afternoon's work.

**Syncing too much.** Entire home directories, photo libraries to every device, large repos. Churn, battery, conflicts, bloat.

**Constant tool migration.** Each switch is work, risk, and disrupted automation. Pick something adequate and stay with it.

**No plan for bad networks.** Works on home Wi-Fi; burns battery over 2G.

**No plan for degraded operation.** Laptop dies; only then discover you can't do critical work from any other device.

**All-or-nothing adoption.** The system isn't protecting you until it's complete, and it may never be complete.

**Forgetting the human layer.** Partner can't access anything if you're incapacitated. No communication fallback.

**Documentation rot.** The system changes; the runbook doesn't. Review at every fire drill and after every significant change.

**Unorganised backups.** Everything backed up, but you can't find the specific item under stress.

**Untracked domain renewal.** Losing a domain cascades into losing email, then everything.

**Underestimating initial seeding.** Expecting "one weekend" for a multi-week first backup.

---

## 15. Phased Plan

Time estimates assume tools are already chosen. Tool selection is additional time, particularly for Phases 2 and 3.

### Phase 1 — Stop the Bleeding (Tier 0, one afternoon)

Password manager on all devices with offline access. 2FA recovery path independent of any single device. Physical printout of vault 2FA recovery, critical recovery codes, and backup encryption passphrases; stored off-site. Verify you can reach your vault from a browser on a device you don't own, including 2FA. Write a one-page "my phone was stolen" note.

Cost: nearly zero. Value: prevents total account lockout.

### Phase 2 — Protect the Irreplaceable (data backup, one weekend to start)

Automated photo backup off phone. Automated file backup from laptop to encrypted remote storage. Database backups from server. Exclusions for build artefacts. Email archive if using multiple providers. Verify one restore end-to-end.

Initial seeding may take weeks for large datasets; seed locally or via physical media and let offsite replication happen gradually.

Value: prevents permanent data loss.

### Phase 3 — Daily Coherence (sync, one weekend)

Working documents synced across machines. Contacts, calendar, notes synced with offline support. Performance tuning: exclusions, throttling, Wi-Fi-only mobile, idle-aware on laptops. Test offline behaviour. Household sync if applicable.

Value: eliminates "left it on the other machine."

### Phase 4 — Reduce Recovery Time (config as code, weeks)

Dotfiles in version control. Package lists captured. Server config codified. Full recovery runbooks (sequences with dependencies, post-theft checklists, communication gap plan) written and stored in multiple locations. Domain and DNS documented. Account inventory completed. Test the recovery sequence on paper; try it once for real.

Value: "a week to rebuild" becomes "a day."

### Phase 5 — Harden (security and resilience)

Full-disk encryption everywhere. Remote wipe on phones. Backup verification automation. Offsite cold backup with key escrow. Dependency cycle audit (draw the graph; check for deadlocks). Bus factor documentation and trusted-person access. Independent monitoring. Power resilience. Ransomware-resistant backup target. Secondary device capability. Spare device ready.

Value: covers less likely but more catastrophic scenarios.

### Phase 6 — Maintain (ongoing, low effort)

Annual fire drill: Tier 0 from borrowed device, recovery sequence walkthrough, cold backup check, runbook review. Cold backup refresh quarterly. Retention review and pruning. Storage cost check. Account inventory refresh. Runbook updates after system changes.

This is the steady state. If earlier phases were done well, it requires very little active effort.

**You can stop at any phase.** Each delivers standalone value. Phase 1 costs an afternoon and prevents the worst outcome. Phase 2 prevents permanent data loss. Phase 3 improves daily life. Beyond that is diminishing returns for most people. Insurance (contents or device-specific) covers the financial cost of replacement hardware and is worth checking independently.

---

## 16. Recovery Procedures

These are reference material for your runbook. Adapt them to your specific setup, then store the result somewhere you can access under stress: vault, physical printout, trusted person.

### 16.1 Phone Loss

1. **Obtain a communication channel.** Borrow a phone or use a partner's device. Reach anyone time-sensitive first.
2. **Access your vault.** Borrowed browser, memorised master password, 2FA from physical printout or hardware key on your person. Do *not* rely on recovery codes stored inside the vault for the vault's own 2FA.
3. **Secure the stolen device.** Remote wipe, session revocation, credential rotation. Before recovery; the thief has a head start.
4. **Restore phone number.** Contact carrier, transfer eSIM or get replacement SIM. You may need identity documents (digital copies in vault).
5. **Set up replacement.** Vendor backup for apps/settings, then reconnect self-hosted sync.

### 16.2 Laptop Loss

1. **Access vault and 2FA.** Already on your phone (unless also lost).
2. **Secure the stolen device.** Session revocation, key rotation.
3. **Assess what's available.** Synced files, code on remotes, documents via web.
4. **Degraded operation.** Critical work from phone or borrowed device while waiting for replacement.
5. **Set up replacement.** Install OS, clone dotfiles, run setup script, restore from backup.

### 16.3 Server Loss

1. **Assess impact.** What depends on this server? Is sync, backup, or monitoring affected? If monitoring ran here, check manually.
2. **Stabilise other devices.** If this was your sync or backup target, verify other devices are working from local copies. Don't assume graceful degradation; confirm it.
3. **Check what's independently available.** Config in version control? Backups on separate storage? Secrets in vault?
4. **Provision and restore.** New instance, replay config, restore data, verify integrity.
5. **Reconnect.** Update DNS, re-establish monitoring, verify backup jobs.
6. **Post-mortem.** What wasn't codified? What took longest? Update the runbook.

### 16.4 Post-Theft Checklist

After any device theft, work through these in addition to the device-specific sequence above.

1. Remote lock and wipe the stolen device.
2. Revoke active sessions on critical services (email, banking, cloud, code hosting).
3. Change passwords for services that were actively logged in.
4. Rotate SSH keys, API tokens, and cached credentials.
5. Notify bank if banking apps were installed.
6. Report to police (often required for insurance).

**Communication during the gap.** Between loss and replacement, your number may be unreachable. Use your pre-agreed fallback: email, a secondary number, a specific platform key people know to check.

**What makes this manageable.** A device-specific list (from your account inventory, section 2.7) of what was logged in and where session revocation controls are. Without preparation: panicked scramble. With a checklist: 30 minutes.