Reading the run logs in Backup by Zaweba

A green tick tells you a backup ran. The log tells you what it actually did. Every run and every verify in Backup by Zaweba writes one, and the Logs tab puts them all in one place, so you can answer questions like which files changed last Tuesday or why a pair turned amber.

What a log records

Each run log lists the files that were copied, the ones that were updated and the ones moved to _zaweba_versions, and for each of those moves it records where the old copy went. Anything that failed is listed with the reason. The log also notes what started the run, such as a schedule or the command line, which clears up the odd moment when you weren't expecting a pair to have run at all.

Verify runs write logs too. When you check an old backup with Verify backup (size and date) or Verify backup with SHA-256 from the card menu, the result is saved with the run logs.

Finding your way around the tab

Open the tab with View > Logs or Ctrl+2. Logs are listed newest first, and you can show all pairs together or narrow the list to one. Pick a log and its full text appears, so you can read it there without opening anything else. From a pair's card menu, View logs is the quick way in when you already know which pair you're interested in.

If you'd rather look at the files directly, Tools > Open the logs folder opens the folder they're kept in, under %APPDATA%\Zaweba\Backup. That's useful when you want to search across many logs with another program, or keep a copy of one.

Questions a log answers

The most common reason to open a log is to find an old copy. When a run replaced or removed a file, the log says which dated folder under _zaweba_versions now holds the previous version. That beats browsing through dated folders by hand.

The next is an amber card. A run that finished with errors or was cancelled turns its card amber, and the log names the files that failed and why, which might be a file held open by another program or a folder you no longer have access to.

A pulled drive is another. An interrupted run stops and the pair goes red with the note that the next run will finish it. The log lists what was left to do.

Then there's the run that stopped at the preview while you were out. If the mass-removal guard halted a Mirror or Synchronise run because too many files would have been moved to versions, that stop is logged too, even when it happened on a schedule.

Making logs part of the routine

You don't need to read every log. The dashboard does the summarising, and a green tick with a recent time is usually enough. But a glance at the newest log for each pair once in a while is a cheap way to catch slow problems, such as a file that fails every night because a program holds it open, or a filter that's leaving out more than you meant.

Logs are also the best record after you change something. Edit a pair's filters or mode, run it, then read the log for that run. If the files listed match what you expected, you can trust the next unattended run. If not, you've found out with your files still safe, since anything a run replaced or removed is sitting in _zaweba_versions.

Scripts benefit as well. A pair started from the command line with --run records that in its log, so runs kicked off by another program, such as Schedule by Zaweba, are just as easy to trace as the ones you start yourself.

The Logs tab is where Backup by Zaweba shows its working, and it's worth knowing your way around it before the day you need it.