Delete a file in a synced folder, and the deletion may reach every connected device. The same goes for a file damaged or encrypted by ransomware. Sync is handy for access, but it is not enough on its own as a backup. A dependable backup keeps recoverable versions outside the original data’s failure path—and you need to know how to retrieve them.
For a beginner developer, valuable data extends beyond source code: uncommitted project files, database samples, IDE settings, encryption keys, password-manager recovery material, and learning-lab notes may all live on one machine. Start with what would be hard or impossible to recreate, then decide how you would recover each item.
Define what recovery needs to achieve
Two measurements help set priorities. The recovery point objective (RPO) is the most data you can afford to lose, measured in time. If a project database changes throughout the day and you cannot lose more than a day’s work, a weekly backup will not do. The recovery time objective (RTO) is how long you can afford to spend getting usable data back. An off-site backup might survive a local disaster but take longer to download than a nearby drive.
These are planning targets, not promises made by a backup product. Set them for each important workload: personal documents, active projects, and any service you operate may need different schedules. A student lab you can rebuild from instructions might tolerate a longer RTO than a client deliverable due tomorrow.
Make a small data inventory
- Irreplaceable files: personal records, original photos, research notes, and work not stored elsewhere.
- Project state: source files, uncommitted changes, local databases, configuration, and documentation. A remote Git repository protects pushed commits, not every file on your machine.
- Recovery dependencies: encryption passphrases, recovery codes, software license records, and environment rebuild instructions. Protect these separately; without a backup key, even an intact backup may be unusable.
- Recreatable material: downloaded installers, build outputs, dependency caches, and temporary files. You can exclude these to shorten backups if you know how to regenerate them.
Inventory devices and accounts, not just folders. A laptop, phone, external disk, and cloud account may each hold different originals. For each item, note where it lives, roughly how large it is, how often it changes, and who is authorized to restore it. This can also reveal a common gap: backing up an application’s files but not the database holding its working data.
Use separate copies for separate failures
The 3-2-1 rule offers a starting point: keep three copies of important data, on two types of storage, with one copy off-site. The working original counts as one. What matters most is separating failure paths. Two folders on one laptop will not help if its drive fails; two drives in the same bag offer little protection against theft.
One setup uses the laptop as the working copy, an external drive for quick local restores, and encrypted off-site storage for a building-level loss. You could instead keep a second drive at another location. Pick what you can manage with your bandwidth, storage, and budget. Drives fail, accounts get locked, and storage services change; no medium stays safe forever.
Protect against deletion and ransomware
Versioned backups keep earlier states rather than replacing the only saved copy. They help when you discover a mistake days later or damaged files have already synced. Choose how long to retain versions—for instance, frequent recent copies and less frequent older ones. Retention uses space, but pruning must not remove the last known-good version before you spot a problem.
Keep at least one backup offline or otherwise protected from ordinary write access. You might connect an external drive for scheduled backups and safely disconnect it afterward, or use storage with immutable versions or tightly restricted deletion permissions. Either approach reduces the chance that malware, a compromised account, or an accidental command can change both the original and its backup. An always-connected drive with the same writable access as your files shares more of their risks.
Limit deletion permissions, too. A backup process needs to create copies; routine user accounts and applications do not need broad control over every retained version. Protect hosted-storage accounts and keep their recovery methods current. Separation helps only if you can reach the copies when your primary machine or account is unavailable.
Choose a backup method that matches the data
A full backup copies everything in scope and is straightforward to restore, but takes more time and storage. An incremental backup saves changes since the previous backup, often speeding up daily runs; a restore may depend on a chain of backup sets. A differential backup saves changes since the last full backup, usually using more space as the cycle goes on in exchange for a simpler restore path. Tools use these terms differently, so check what their restores require before settling on a schedule.
A disk image can help recover a whole machine, including its operating system and installed applications. A file-level backup is often easier when you need one document or project directory. If reinstalling your development environment is easy but recovering years of notes is not, prioritize file-level copies and keep brief setup instructions. If rebuilding the machine would cause costly downtime, consider image-based recovery as well.
Git history helps with source changes, but it is not a complete backup policy. It may miss ignored files, unpushed local branches, large datasets, secrets kept elsewhere, and the remote account itself. Keep secrets out of source control while backing up necessary credentials through a suitably protected method. Snapshots on the same device can speed recovery from accidental edits, but they will not help if the device is lost.
Handle databases as databases
Copying a live database’s files without its supported backup procedure can leave you with an inconsistent copy; transactions may still be in progress. Use the database’s documented dump, snapshot, or backup mechanism, and check whether it captures a consistent point in time. A scheduled logical export may be enough for a small learning application. A production service with a short RPO may need database-aware backups and transaction-log handling.
Restoring may also depend on the database engine version, extensions, user permissions, and application configuration. Save enough non-secret configuration detail to rebuild the environment, and keep required secrets in a protected recovery location. Test restores in an isolated instance rather than overwriting the live database.
Make the schedule automatic and visible
Manual backups slip when work gets busy. Automate them to match your RPO, then make sure the jobs keep running. A nightly job cannot meet a one-hour RPO, and a job that quietly stopped three months ago meets no useful schedule.
Track at least the last successful run, the amount of data captured, free space at the destination, and reported errors. A sudden drop in backup size may mean a folder moved or was excluded; a jump may mean temporary build files are filling storage. Recheck exclusions when you reorganize projects, upgrade an operating system, or change where an application stores its data.
Keep retention easy to understand: daily copies for a short recent window, for example, with periodic copies kept longer. Estimate storage from how much data changes, not just the size of the first full backup. Leave room for new versions, and make sure old copies expire only after replacement backups succeed.
Encrypt backups without losing the keys
A backup can gather a great deal of sensitive information in one place. Encrypt portable media and off-site copies, especially if they contain identity documents, private code, or database records. Provider-side encryption at rest and encryption before upload set different trust boundaries. With client-side encryption, the provider does not need the plaintext key, but key management falls more heavily on you.
Use a strong, unique passphrase or a managed key mechanism suited to the tool. Document how to recover the key if your primary device is lost. A recovery code stored only on the laptop you are backing up is no help when that laptop is gone. Keep a protected copy elsewhere and restrict it to people authorized to restore the data. Then test a restore using the keys and instructions you would actually have in an emergency.
Encryption does not replace access control. Someone who can sign in to a backup account, change retention, or delete storage may still cause a loss without reading the files. Review account access after changing devices or ending a shared project, and periodically otherwise.
Test restores, not just backup completion
A success notification usually confirms that a job wrote data, not that you can use the result. Test a small recovery by retrieving an older file version. Periodically, restore a project or database to a separate location, open the files, and run the application or database checks that show the data makes sense.
Keep tests away from the working copy: use a temporary directory or spare machine so a mistaken command cannot overwrite the originals. Handle sensitive datasets in a suitably protected test environment and remove temporary restored copies afterward. Time the process as well. If downloading and rebuilding takes longer than your RTO allows, you may need a faster local copy or better recovery instructions.
Write a short recovery record rather than relying on memory. Include where the backups are, their available date range, the tool needed to open them, key-recovery steps, restore order, and how to check the result. Keep it accessible if your primary computer fails, without putting passwords in a plain-text note.
A workable plan for one development laptop
- List critical folders and application data, including projects, notes, and local database exports. Exclude only what you can confidently regenerate.
- Set an RPO for active work and an RTO for getting back to a usable system. Choose a backup frequency and destinations that can meet both.
- Schedule versioned file backups to an encrypted external drive. Disconnect it after the job if your workflow permits.
- Keep a separately protected off-site copy of critical data, with access and retention configured independently of the laptop.
- Check job results regularly and test a small restore each month. After major setup changes, test a broader recovery that includes configuration and a database export.
Suppose a project’s local database changes every afternoon. Schedule a consistent database export before the file backup runs, and confirm that the export is included. On your next test day, restore it into a fresh local instance and inspect a few expected records. A green file-backup status alone would not tell you whether that database can be recovered.
