Urbackup is cross platform, does imaging, include/exclude file backup and data retention policies that are easy to use. You can even restore over the network. Unlike many other backup solutions, files are stored in a format where you can get a hold of your files Manually, if need be.
https://dietpi.com/ dietpi can quickly set up your backup server within a few minutes on most SBC Single Board Computers like the Raspberry Pi.
I have multiple backups that run daily against a NAS / B2 / etc. and it's always worked flawlessly.
It does cost money, but its a one-time fee.
Just to be clear, you get one year of free updates and additional years will be $25/yr (per computer). Reasonable in my opinion.
I store all data to a home NAS drive, and then on a regular basis run a ROBOCOPY batch file to a USB hard drive. I rotate several drives (all cold & offline) to have some versoning/protection against bit-rot and undetected corruption.
Once or twice a year I put a drive in a ziplock bag (water tight) to an off-site location that is fireproof and reasonably burglar proof.
I do not trust SaaS or online backups. Too easy to have my online copy get hacked or have my backup provider go out of business. My fate is in my hands.
Edit: ngl, it looks like an asian spyware for quite a while, but it did its job eventually.
I do it all the time. Same old way for years. No struggle.
Much quicker and easier than going through the following message ;)
First of all get your entire C: volume cleared of all massive amounts of valuable data that is best routinely stored or archived on a different volume than Windows is on. External drives can really be ideal for user data so that when you restore Windows in the future you have that same external filing cabinet to pull from.
This way most people should be able to get their C: volume down to about 20 to 30 GB these days.
This is really the most time-consuming part of the process usually.
Also you almost never want to install programs to volumes other than C:, this can screw up all kinds of backup approaches. You want your installed programs to be part of your Windows "system" on the C: volume and be backed up & recovered right along with Windows.
Then comprehensive backup can be made using Windows' built-in DISM tool at the command line, the entire contents of the C: volume is compressed by default to about half that size as it is backed up to a WIM file. Big resulting WIM files like this need a lot of space on some other storage volume like D:, E:, or F:, etc.
I boot to the Windows Install USB stick, not to reinstall, but click "repair my computer" then progress onward to end up at the command prompt. This is not the same as the command prompt you can get on your desktop when Windows is running. The install USB is like the "Recovery Console" and boots to a virtual X: volume as a ramdrive, leaving your regular C: volume dormant as a mere storage drive, and C: naturally just happens to hold your working Windows installation (plus whatever else you have there). So now you can back up the whole C: volume while none of its files are actively in use, saving the backup as the proper WIM file type that is intended for recovery from the same type command line or recovery console in the future.
The command is like this:
DISM.EXE /capture-image /ImageFile:D:\backups\w11_240929.wim /CaptureDir:C:\ /Name:w11_240929
-this takes a while but there is a progress indicator.
This is the way I capture an entire C: volume and save it into a pre-existing D:\backups folder of an external storage drive. You name your own WIM file and /Name text, I mostly use the same names for both.
These backups need to be checked for reliability, and recovery is not always a one-step process but it is the Windows way. DISM is very powerful and worthy of great study, not so complex if you limit it to backup & recovery though. You will use the DISM /apply-image routine, and you can place the captured system ("recover" it) onto any properly formatted volume whether it is in the MBR or GPT drive layout. But, unless you are recovering to the exact partition that you backed up from, you will usually still need to then add your own fresh boot files specifically crafted for either scenario, using the BCDBOOT command. If you've never done it before it only takes a little bit of rehearsal, and then it makes more sense than anything. Recovery is important so it can be ideal to rehearse using a spare SSD on a desktop to confirm your workflow before migrating to DISM for laptops where the SSD is less physically accessible.
example:
DISM.EXE /Apply-Image /ImageFile:D:\backups\w11_240929.wim /index:1 /ApplyDir:G:\
-which applies your previously saved w11 backup from D:\backups\w11_240929.wim to a freshly formatted G: volume
--this also takes a while but there is a progress indicator.
Now that you have that desired Windows fileset recovered onto your G: volume, if you have never booted Windows on that partition before, you will need to create fresh boot files on that SSD that will point to the Windows you now have placed on G:.
For this, first you need to assign an alphabetical letter to the "boot volume" usually "hidden" in a separate partition on that same drive hardware. This makes the boot-file-storage volume become "visible" and BCDBOOT will be able to target it as the desired hardware boot volume. For GPT this would be the "ESP" partition, for MBR it's the "Active" partition. You need to run DISKPART from the command line, select what Microsoft here calls the "system" partition and assign it a letter, something like the letter S: seems appropriate for a "system-boot" partition. You still won't be able to access the volume from File Explorer, but will in command prompt and BCDBOOT will now function as desired. After that the volume letter "S:" will disappear upon reboot. Read the docs or help on DISKPART but this is a simple process.
Then once the proper target boot files volume is assigned as volume S:
for GPT:
BCDBOOT.EXE g:\windows /s s: /f UEFI
creates a new folder; s:\EFI\Microsoft\Boot\bcd, on an empty S: volume (or one not already containing such a folder)
-this bcd makes the Windows OS on G: (recovered or not) be the one that boots when this particular SSD is chosen by the UEFI as the desired boot device, using the S: volume as the expected typical ESP boot partition.
- or -
adds a boot menu entry pointing to g:\windows, into a pre-existing s:\EFI\Microsoft\Boot\bcd file, turning it into a multiboot menu in the process, this is a little more advanced.
for MBR:
BCDBOOT.EXE g:\windows /s s: /f BIOS
creates a new folder; s:\Boot\bcd, on an empty S: volume (or one not already containing such a folder) -this bcd makes the Windows OS on G: (recovered or not) be the one that boots when this particular SSD is chosen by the BIOS as the desired boot device, when the S: volume is properly designated or "marked" as the "Active" boot volume. [0]
- or -
adds a boot menu entry pointing to g:\windows, into a pre-existing s:\Boot\bcd file, turning it into a multiboot menu in the process, this is a little more advanced.
[0] There also needs to be a proper Master Boot Record in sector 0 for BIOS booting, if not already present one can be written using BOOTSECT with the /mbr switch;
BOOTSECT.EXE /nt60 s: /force /mbr
-which (re)writes the MBR of the SSD containing the S: volume, along with the Volume Boot Sector of the S: volume, while leaving everything else like partitions and data untouched. IOW also a harmless command on a perfectly working MBR/BIOS system dedicated to Windows NT6 (currently Windows 10 is the only "supported" Windows under BIOS any more but you can make W11 work if you try). However an MBR is not needed on a GPT drive layout, actually GPT is usually better off with nothing but zeros in the first 440 bytes of sector 0.
Here's to pleasant backups and well-rehearsed recovery :)
