Unexpected values in env vars BVCKUP_TIME_STARTED and BVCKUP_TIME_ATTEMPTED
Aug 23, 2020
In BVCKUP2 v81.6.1 on Win10 Pro, I have a post-backup script configured to use two BVCKUP environment variables:
The values I'm seeing for FINISHED are like this...
...which make sense and mirror what is documented here:
But the values I'm seeing for STARTED are like this...
...where I was expecting date/time strings like those for FINISHED,
I thought I might be able to work around this by using BVCKUP_TIME_ATTEMPTED instead of STARTED, but I get the same kind of puzzling results as with STARTED.
Have I misunderstood what BVCKUP_TIME_STARTED should provide? My apologies if I've missed something fundamental.
Alex Pankratov :
Aug 23, 2020
I cannot reproduce this. Also, the values you quoted look like the tail part of a full date-time value, i.e. just seconds and milliseconds.
Can you set your post-backup command to
cmd /k set
and check what the values you see for _STARTED and _ATTEMPTED?
Here's what I see with 81.6.1 -
Aug 23, 2020
Thank you for the quick reply and helpful suggestion. The problem turned out to be a very basic one of my own making in the course of debugging a chain of scripts. I was sampling the env vars at the wrong point. Context FWIW:
Some years ago, I wrote a suite of Windows shell scripts to run backups at home using several free apps -- Robocopy, Sysinternals' disk2VHD, Window's wbadmin and others -- after making shadow copies using Microsoft's free example VSS client. Each backup script calls a logging script that writes backups results to a central log.
I recently started needing to back up a family member's OneDrive folder. I didn't get that working using Robocopy, so I tried BVCKUP2 and had success. My env var trouble came in getting a post-backup script in BVCKUP2 to call the logging script. I first thought I could use BVCKUP variables like $STATUS as command line arguments to the post-backup script, then realized I needed to use the BVCKUP env vars instead.
That should have been straightforward because the logging script was built to read env vars created by my backup scripts. My new post-backup script for BVCKUP2 just would need to read some BVCKUP2 env vars and write their values to the corresponding env vars used by the logging script, then run the logging script.
My very basic error in debugging was to sample the env var values after the logging script had run, rather than straight out of BVCKUP2. The logging script had messed things up because the time and date strings provided by BVCKUP2 are a little different from what it expected.
Thank you for making such a robust and flexible product and thank you again for your help here!