The support forum

Archive backup copies and time setting

beethoven :

Apr 15, 2017

Just wondering/ wishing to confirm  how to use the time setting for archiving deleted items?  If you set this to 2 weeks and have a manual backup setup as opposed to continuous, does that mean that 3 weeks after the second backup any files deleted from the fist backup are gone?  So for manual backups you may want to choose longer periods?

beethoven :

Apr 15, 2017

Looking at a bckup (continuous) of a password file I set this to 26 weeks. I don't quite understand what the archived items actually are. The original file does not get deleted, just amended several times a week. The backup of deleted does show me 26 weeks of deleted items but none of these can be opened. Other backups of deleted files (keeping 2 weeks) are available and can be opened.

Alex Pankratov :

Apr 15, 2017

Re: retention period - when a file is placed in the archive, it is tagged with the date/time of archival. It is this tag is used to decide when to delete it from the archive.

The deletion of files from the archive (referred to as "archive pruning" in the log) is carried out as a part of a backup run. It doesn't happen on its own.

So if you have a manual backup that you run every 3 weeks or so, then you archive will indeed be emptied at the beginning of every run if the retention period is at its default of 2 weeks.


The second post I don't quote understand, sorry. Specifically "can't be opened" part and how you managed to accumulate 26 weeks worth of deleted files.

Archiving applies to backup copies of files _deleted_ at source. You can enable it to also handle _modified_ files, but this requires an explicit INI edit as per

beethoven :

Apr 15, 2017

thank you - part 1 is now clear.

Re part 2 - the file being backed up is a password file. The set up for backup is to backup continuously, with destination snapshot, delta copying and to archive backup copies. I set this up to delete archives after 26 weeks.
The actual source file does not get deleted at all, only modified frequently as you would expect from a password file. So while the actual latest source file is showing in the destination folder, I am surprised to even see any archives/deleted.  Interestingly enough they go back 26 weeks, so it seems to me that for this file Bvckup treats a modification like a deletion, except that these archives then are corrupted and cannot be used.  Could there be a problem for Bvckup with respect to recognising that the original file is the same due to the fact that the file is encrypted?

Alex Pankratov :

Apr 19, 2017

I am surprised to even see any archives/deleted.  

Have you looked in backup log to see what's happening? There is a good chance that your password file _is_ in fact deleted and then re-created from scratch with every attempt. If there's a sufficient delay between these actions, bvckup2 will propagate them separately.

Also, the fact that your backup copies appear "corrupted" likely means that file is backed up in some ephemeral state, e.g. while it is still being updated.

File being encrypted is irrelevant to what you are seeing. Encrypted or not, it's all just some opaque data as far as Bvckup 2 is concerned.

I would suggest taking a closer look at a backup log and at a log of the software that manages this password file. You should be able to piece together what exactly is happening.

New topic

Made by Pipemetrics in Switzerland

Dev blog
Miscellanea Press resources
On robocopy

Legal Terms