appuza
Decide what loss you are protecting against
A backup plan starts with a failure scenario. A deleted note, a damaged laptop and a mistaken bulk rename are different problems. Sync can make the same current files available on several devices, but a harmful change may also reach those devices. Obsidian's official backup guidance explicitly distinguishes syncing from backup and recommends a separate copy for recovery. Treat that as a design requirement: you need a way to return to a known earlier state, not just another view of the current one.
For a personal vault, write down how much work you could afford to recreate and how long you could wait to regain access. A student making daily notes may tolerate losing an hour but not a week. A rarely updated reference archive has different needs. These are planning choices, not promises that a particular service makes. They help you choose a backup frequency and destination that match the actual value of the files.
Identify the complete vault
Find the vault folder and inspect what it contains before selecting files for backup. Notes alone may not be enough. Attachments, linked images, PDFs and configuration can matter to the way the vault works. A copied Markdown file may open correctly while every embedded image is missing. Make a small inventory of the file types and any folders located outside the vault that your notes depend on.
Do not assume a link means the linked file is inside the backup. A note can refer to a file elsewhere on the computer or to a web page that may later disappear. Decide whether those external dependencies need their own copies, subject to your rights to retain them. The purpose of the inventory is to define what “restored” means. For one person, readable text is enough. For another, the exact folder structure and attachments are essential to continue a research project.
Choose one source for scheduled copies
If the vault syncs across devices, choose one reliable device as the source of your scheduled backups. Obsidian's help recommends this approach to avoid confusing the backup process across multiple devices. Pick a machine that is regularly online and has the full set of files available. A device with placeholder files or incomplete downloads can produce a backup that looks populated but lacks the actual content you need.
Keep more than one historical copy. A single backup that is overwritten every night may preserve yesterday's unnoticed mistake as today's only recovery point. The exact retention schedule depends on space and how quickly you notice problems. A practical plan might keep recent daily copies and older weekly copies, but the important property is the ability to recover from a mistake discovered late. Write down the schedule so that it is a policy you can check rather than a vague belief that backups happen.
Put recovery copies outside the main failure path
A copy on the same internal drive can help with an accidental edit but will not help if that drive fails. A removable drive, another machine or a suitable backup service can provide separation. Consider what happens if the laptop is lost, the account is locked or a folder is accidentally deleted. There is no single destination that solves every failure. Choose a combination whose weaknesses you understand and can maintain.
If the vault contains sensitive information, include access and encryption in the plan. Do not create an unprotected archive simply because the working app feels private. Conversely, an encrypted backup is useless if its recovery key exists only on the lost device. Store recovery information through an appropriate independent method. Keep this separate from ordinary notes that sync everywhere. The backup destination should be accessible to the person who needs to restore it, while remaining protected from people who should not read the contents.
Rehearse restoration into a new folder
The safest test restores a copy into a temporary folder, leaving the working vault untouched. Open several notes from different parts of the archive. Check a recent note, an older note, an attachment and a link between notes. Search for a distinctive phrase that you know should be present. If settings are part of your recovery goal, check them too, while avoiding untrusted plugin execution in a test environment.
Record the backup date and what you verified. A successful archive download is not the same as a successful restore. If the test reveals missing attachments, fix the backup selection and repeat the check. If the restored files are readable but the app layout differs, decide whether that matters to your recovery goal. The rehearsal should answer a concrete question: can you resume the work from this copy? It is not necessary to reproduce every cosmetic preference if the essential information is intact.
Make the plan easy to keep
A backup routine that requires a long manual ritual will eventually be skipped. Automate the copying where appropriate, but keep a visible way to confirm recent success. Set a reminder to perform another restore rehearsal after major changes, such as moving the vault or changing storage providers. Check destination space and retention so that silent failures do not accumulate. The routine should produce evidence of recoverability, not just reassuring notifications.
Keep a short recovery note outside the vault describing the source device, backup location, restore procedure and where authorized recovery credentials are held. Avoid placing secrets directly in that note. If you are unavailable, another authorized person should be able to understand the plan. The final standard is simple: an earlier copy exists, you can reach it without the original device and you have opened it successfully. That is a much stronger basis for confidence than seeing the same notes on two synced screens.
Official references
These are editorial walkthroughs based on documented features, not claims of a completed device test. Product behavior can change. Send a correction.