How to make an Anki backup before migration that you can explain

List the collection scope, written fields, media, native card behavior, and review information that matter to your routine. Mark what must remain usable if the trial fails. The current backup manual distinguishes automatic card-data backups from media-inclusive manual recovery options. Read that distinction before relying on whichever file is easiest to find. The recovery requirement is yours to define; the manual explains which documented method fits it.

In the fictional scenario, the learner has personally authored text questions, image prompts, and a vocabulary deck with established review history. A text sample can support the trial, but it does not satisfy the recovery list. They choose a native recovery method appropriate to that list and record the selected scope and options. They also keep the permitted original sources needed to verify answers. Restoring a technically intact collection would not correct a source mistake introduced earlier, so recovery completeness and content accuracy remain separate checks. A good plan names both without confusing them.

Inventory the devices you actually use and the last meaningful work done on each. A phone may contain recent review activity while a laptop contains newly edited notes. Do not assume the device used most often is automatically the complete source of truth. Record what is unique before starting a migration or a one-way synchronization decision. If copies differ, preserve them separately and consult the current syncing documentation before allowing one to replace another.

The fictional learner discovers that a tablet has an unsynced source correction. They preserve the relevant state and resolve the discrepancy before exporting a supposedly final collection. Without that check, a polished recovery file could omit the very change they wanted to keep. Use concrete examples to establish completeness: a recent note edit, a known new record, and a media-dependent prompt. Counts alone can look similar across copies while their content differs. The device inventory is a short explanation of the collection’s current state, not a permanent technical asset register.

Keep a copy somewhere other than the only device holding the active collection. Choose storage you can access when that device is unavailable, with permissions appropriate to the content. Record the filename, date, scope, and intended use in a short recovery note. Avoid names such as final-final that conceal which operation produced the file. A clear name does not prove completeness, but it reduces the chance of selecting the wrong candidate during a stressful recovery.

Check the copy after saving it. Confirm that the file is present in the intended location and that its recorded scope matches the export choices. For sensitive personal notes or restricted course material, inspect who can access the storage location before placing a backup there. A recovery copy should not accidentally become a public distribution of a private deck. Keep the source ledger and essential instructions with the plan where appropriate, without embedding credentials or unrelated private information. The goal is practical access to the right copy when needed, not accumulating many indistinguishable files.

Read the documented restore procedure and its replacement consequences before testing it against anything important. Restoring an earlier state can discard later work, so identify the time boundary and preserve current copies where necessary. Do not open a collection package on the active setup merely to prove that it is readable if you have not understood what import will replace. Use a safe, documented test process that does not put the only working collection at risk.

For the fictional learner, the recovery note answers four questions: which file, which scope, what later changes could be lost, and what media is included. They inspect representative content through a recoverable process and compare it with known examples. This does not require pretending that a brief test guarantees every record. It establishes that the process is understood and that obvious scope omissions have been checked. If any consequence remains unclear, postpone the migration operation. A separate source-drafting trial can often proceed with copied text while the native collection remains untouched.

A useful rehearsal question is: if the current laptop stopped working now, which exact copy would you use and what would still be missing? Answer without relying on the active app being open. In the fictional scenario, that exposes an image folder stored only beside the active collection. The learner adjusts the recovery plan before testing another workflow. The exercise is a concrete completeness check rather than a claim that a particular storage service guarantees recovery.

Choose a representative, permitted text sample rather than transferring the whole collection first. Write the task you want to compare and its acceptance criteria. A source-drafting trial might require a clear question, a verified answer, and a traceable source. It does not require deleting Anki, resetting cards, or changing the active scheduler. Keep those unrelated operations outside the trial so any observed benefit or failure can be attributed to the task being tested.

In the fictional example, the learner selects a short chapter explanation and a few personally authored questions. They inspect field mapping and resulting fronts before expanding. If the trial reveals a clearer explanation, they can retain that wording without moving native history anywhere. If the receiving workflow is unsuitable, they stop with the original review system intact. That is an informative outcome, not a failed commitment to switch tools. A reversible trial should produce evidence about a concrete source task while preserving the option to keep the established collection unchanged.

Before expansion, compare the result with the written requirements. Confirm that the recovery copy remains available, the original sources are retained where permitted, and the receiving questions preserve meaning. Identify anything the new workflow does not carry. If a task depends on native media or generated card behavior, decide whether it should stay in Anki. A migration plan can have a deliberate division of work instead of an all-or-nothing destination.

Elly’s CSV, TSV, and TXT workflow does not preserve Anki templates, media, scheduling, or review history. Use it for a supported source-based task and keep the native collection when those features matter. Finish with a short decision record: what was tested, what passed, what remains in Anki, and what would happen if you stop. This record keeps the evaluation from drifting into an irreversible cleanup simply because a first upload succeeded. Recovery readiness should make careful experimentation easier, while the task evidence determines whether any larger transfer is justified.