Introduction
Backing up the credentials, recovery data, or metadata associated with hardware-backed logins like [Trezor Login] is a serious responsibility. The file format you choose affects portability, security, auditability and long-term durability. Below you’ll find a thorough exploration of file formats, how to protect them, typical patterns for individuals and organizations, anti-patterns to avoid, and concrete restoration checklists.
Throughout this guide I use the term backup artifact to mean any stored representation of secret or recovery data — whether that’s a printed sheet of words, an encrypted archive, or a hardware-backed export. Aim to minimize the number of places sensitive artifacts are stored, while maximizing the resilience and testability of your recovery process. Where possible, assume an adversary can read any online storage and plan accordingly.
High-level guidance (summary)
Prefer formats that are: standard (widely supported), auditable (checksums, signatures), and encryptable with strong algorithms. Combine an encrypted digital copy (GPG/ZIP) with an offline physical copy (PDF, printed words) stored in a secure location. Test restores periodically.
Common formats explained
Plain text (.txt)
Plain text offers universal compatibility: any system can open and inspect a .txt backup. For human-readable recovery phrases or short keys, this can be helpful during restoration. However, text files have no built-in confidentiality or integrity checks.
When to use: Only in tightly controlled workflows where the file is immediately encrypted or printed and then removed. Never keep raw text backups in cloud storage or shared folders.
Encrypted archive (ZIP / 7z)
Encrypted archives are practical for multi-file backups (e.g., config JSON + certificate). Use AES-256 and a robust key derivation function (PBKDF2, Argon2) on the passphrase. Tools like 7-Zip or OpenSSL-backed zips provide better options than legacy zip implementations.
Tips: Avoid weak passphrases; combine with hardware-stored passphrases where possible. Document the tool and exact command used to create the archive so you can reproduce the restore environment later.
GPG / OpenPGP (.gpg / .asc)
OpenPGP provides both confidentiality and authenticity. Signing and encrypting backups allows you to verify the source and to detect tampering. For organizations, GPG integrates with existing key management workflows and can be automated through CI/CD for scheduled backups.
Important: Keep private keys offline or in protected hardware tokens when possible. Rotate keys and publish revocation certificates according to your policy.
JSON (structured)
Structured JSON makes it easy to include metadata: version, timestamp, device IDs, and checksums. For scripted or automated restores, well-documented JSON schemas reduce ambiguity. Always encrypt JSON that contains secrets; never rely on schema to provide confidentiality.
Best practice: include a SHA-256 checksum inside (or as a companion file) and use deterministic JSON serialization to guarantee identical byte sequences for signing and verification.
PDF (printable backup)
Human-readable, printable PDFs are ideal for offline, physical storage. Layout the recovery words in large, plainly spaced text, include a checksum and optionally QR encodings for short fragments. A printed PDF stored securely (safe, safety-deposit box) is resilient to many digital threats.
Be careful: If you print and then later scan OCR back into a device, errors from OCR can cause restore failure. Prefer manual transcription checks when re-digitalizing.
Images / QR codes (PNG / SVG)
QR codes and image-based encodings offer quick transfers between devices. SVG is scalable and ideal for printing; PNG is widely supported. However, long secrets encoded as single QR codes are fragile; scanning errors or camera malware can cause trouble.
Break long secrets into chunks with checksums, and never leave QR images unencrypted on cloud-synced drives or public devices.
Hardware-backed exports
Storing backup artifacts on hardware tokens, smartcards, or HSMs adds a robust layer of physical isolation. These are not file types per se, but using them as the primary backup location drastically reduces exposure to remote attackers.
Trade-off: costs, provisioning complexity and vendor reliance. Combine hardware-backed storage with offline printed copies for the best resilience.
Patterns: how to combine formats
It’s rarely sufficient to rely on a single format. Use complementary backups: an encrypted digital copy for quick recoveries + a printed PDF for long-term offline storage. Keep copies in geographically separated and access-controlled locations. For organizations, store one digital copy in a dedicated secure backup service (S3 with server-side encryption and restricted ACLs) and one copy in offline cold storage.
Security controls and metadata
Include metadata such as creation date, schema version, device model, and checksums. Use detached signatures or embed signatures and checksums in the backup file. Always record the exact command or tool used to create the artifact; this helps later when trying to restore from older formats.
Anti-patterns to avoid
Do not store raw recovery phrases in cloud drives without encryption. Avoid storing backups in proprietary, undocumented formats that cannot be inspected or restored without vendor tooling. Never reuse passphrases across unrelated assets. Avoid single points of failure: if the backup and the passphrase are in the same place, you lose redundancy.
Restore checklist (concise)
- Identify the artifact and verify its checksum or signature.
- Decrypt/unwrap using the documented tool and the correct passphrase/hardware token.
- Run a harmless test: verify the key signs a message or check addresses against a read-only node before making transactions.
- Document the process and update your recovery playbook after each restore test.
Automation & organizational advice
For teams, automate periodic encrypted exports using GPG or OpenSSL with rotation policies. Store KMS-wrapped keys in cloud key management systems where permitted, with strict IAM controls. Maintain an offline recovery runbook that lists step-by-step instructions, contact points, and contingency plans in case of catastrophic failure.
Final recommendations
For most users: keep an encrypted archive (GPG or AES-256 zip) stored in at least two different secure locations and a printed PDF stored offline in a safe place. For high-value or organizational accounts, add hardware-backed storage and clearly documented, tested recovery procedures. Always assume that any online store can be read, and plan backups accordingly.
If you want, I can generate printable PDF templates, a deterministic JSON schema for automated backups, or sample scripts (OpenSSL/GPG) to create encrypted backups. Tell me your preferred format and I’ll craft the files.