Your tech is a lifeline while traveling. The data is what’s valuable. Files, photos, logins, and credentials can be irreplaceable.

So it should be obvious that you need backups. But it’s less obvious how many or which kinds of backups to create. There’s the 3-2-1 hueristic: Keep at least 3 copies of your data (the original plus two backups), store them on 2 different types of storage media, and ensure at least 1 copy is stored offsite to protect against local disasters.

3-2-1 is fine for personal backups at home. But there is urgency in travel situations. It’s not enough to eventually get your data back.

In business lingo, we might have an RTO (Recovery Time Objective). Here, we’re just going to assume you want your data back quickly – meaning you don’t get to travel home first, or wait for an appointment with the embassy or whatever.

For backups to be restored quickly, you need to have multiple possible avenues to download and use them and they need to work even in unusual circumstances (for instance, you may not have access to a second factor for authentication).

A Disaster Recovery Scenario is a conceptual strategy where you work backwards from a hypothetical data-loss situation to design backups. The backups will be base on a list of assumptions about your data-loss situation.

A DR Scenario is a list of assumptions. Your assumptions should include facts about the world, the nature of the data loss, and your available resources. Later, once you start building backups, you can add assumptions about the backups themselves.

A good place to start is what data was lost?

My DR Scenario:

1. My phone, laptop, and external SSD have all been stolen.
2. I’m traveling and do not have access to my other backup mediums distributed in North Carolina.
3. The Internet still exists.
4. Backbone infrastructure where I am located does not restrict connectivity to my offsite backups.
5. I have access to new, blank devices on which to recover my data.
6. No more than one of the public offsite storage locations for the boostrap is broken or blocked.
   • If the cause of this blockage was an attacker, it was unrelated to the random theft of my devices and they have not gained access to my system itself. Hence, the private bucket for the vault is safe and unknown to the attacker.

Number 6 looks a bit weird because I have tiered backups. This is a common strategy where you widely distribute a small backup (called the “bootstrap”). The bootstrap is cheap and fast. Then a second backup tier (I call mine the “vault”) contains the rest of the data, and it can only be accessed once you’ve restored a bootstrap.