Esta es una versión anterior. La versión actual es 0.5.5. GUARD 0.5.5 · Fecha de publicación:
Archivos de instalación 0.5.4
| Arquitectura | Tipo | Ámbito | Tamaño del archivo | Descargar | SHA256 |
|---|---|---|---|---|---|
| Cualquier procesador | ZIP → Portable | — | — | github.com | VirusTotal |
El enlace y el SHA256 proceden del manifiesto comunitario del Administrador de paquetes de Windows. Conviene comparar el hash del archivo descargado antes de ejecutarlo.
Notas de la versión
GUARD v0.5.4 is a data-safety release. A use-case audit turned up four ways GUARD could break a backup, or tell you it had protected something when it hadn't.
Fixed
- A Mirror-mode folder pair could delete the rest of your backup. Typing . as the destination subfolder - a reasonable way to ask for "put these files at the top of the backup drive" - sent that pair to the destination root, and the check that stops two pairs mirroring into the same place didn't recognize it as the root, so the save went through and the next run's mirror deleted every other folder's backup. GUARD now reads . as the root it is, and blocks the save the way it already blocks two pairs sharing a folder.
- A backup whose source folders were all missing reported success. If the drive holding them didn't mount, or a network share was down, the run still finished green and an unattended run raised the "finished successfully" notification, so you could go weeks believing you were protected while nothing was being copied. A source that isn't there is now reported as an error. If you back up a drive that isn't always connected, runs made while it's absent will now report an error instead of success.
- Updating while a scheduled backup was running could leave a broken install. GUARD waited for its own window to close, but not for a scheduled backup, which runs as a second GUARD process. The update could unpack over files still in use and leave the folder part old and part new, with GUARD never restarting. It now waits for every GUARD process, and will abandon an update rather than unpack over one that's still running.
- The scheduled system image could be left switched on, or never switched on at all. GUARD reported the schedule as saved whether or not Windows accepted the change: one you switched off could keep taking images on schedule, and one you switched on could never be registered if the Administrator prompt was declined. Either way the page showed the schedule as saved and Save was greyed out, so there was no way to try again. GUARD now checks what Windows actually did, says so when it didn't take, keeps Save available to retry, and notices at startup if the scheduled image has gone missing.
Full changelog: https://github.com/PlanetLinux98/guard/blob/main/CHANGELOG.md#054---2026-08-06
