Almost nobody discovers their backup was broken at a convenient moment. They discover it the day the drive dies — and find that the nightly job had been failing for five months because an external disk was unplugged one Tuesday, or that the destination filled up and every run since has quietly errored out, or that the files are all there but one of them has been silently rotting on the disk since last year. The backup existed. It just wasn’t true.<\/p>\n
BackupDesk<\/strong> is a scheduled backup tool for Windows, released this month, built around a single stubborn idea: a backup tool has one job, and lying about whether it did that job is worse than not existing. It backs up folders on a schedule, keeps a history you control, and tells you plainly what it did — including the parts you would rather not hear.<\/p>\n If you have used File History, OneDrive or Google Drive, BackupDesk is a different kind of thing. Those continuously mirror a folder somewhere, which is useful, but a mirror faithfully reproduces your mistakes: delete a file, encrypt it with ransomware, or save a bad version over a good one, and the mirror dutifully copies that too.<\/p>\n BackupDesk instead takes deliberate backups at levels you choose<\/strong> and keeps a history of them. You describe what to protect, where it goes and when it runs, and a background service does the work — whether or not the window is open. That is what lets a backup happen at 2am while you are asleep.<\/p>\n Every scheduled run happens at a level you pick. The difference between them is the single most useful thing to understand about any backup tool:<\/p>\n The trade-off is space against resilience. Differentials<\/strong> grow larger each day until the next full, but a damaged one only costs you that one backup. Incrementals<\/strong> stay small every day — but they form a chain, and a single damaged incremental spoils every backup made after it.<\/p>\n BackupDesk shows you this where you choose levels, and again where you delete backups. It is not trying to talk you out of incrementals; it is the information you need to make the choice deliberately rather than by accident. And if you would rather not think about it at all, there are presets — Standard<\/strong>, Most resilient<\/strong>, Smallest daily backups<\/strong> and Manual only<\/strong> — each of which you can edit afterwards, because they are starting points rather than locked modes.<\/p>\n The first run copies everything, and takes as long as that sounds. After that, BackupDesk checks each file’s size and modification time and skips the unchanged ones without reading them<\/em>. That is what makes later runs feel almost instant — not the speed of the copying, but the sheer amount of work avoided.<\/p>\n Files that have<\/em> changed are read and hashed with SHA-256<\/strong>, which catches a case that trips up cruder tools: a file whose timestamp moved but whose contents did not is correctly recognised as unchanged, rather than copied again for nothing.<\/p>\nIt is a job, not a mirror<\/h2>\n
Three levels, and the honest trade-off between them<\/h2>\n
\n\n
\n \nLevel<\/th>\n What it stores<\/th>\n What it needs to restore<\/th>\n<\/tr>\n<\/thead>\n \n Full<\/strong><\/td>\n Everything.<\/td>\n Nothing else. It stands alone.<\/td>\n<\/tr>\n \n Differential<\/strong><\/td>\n Everything changed since the last full<\/strong>.<\/td>\n Its full, and nothing else.<\/td>\n<\/tr>\n \n Incremental<\/strong><\/td>\n Everything changed since the previous backup of any level<\/strong>.<\/td>\n Its full and every incremental since<\/em>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Why the first backup is slow and the rest are fast<\/h2>\n