The support forum

Media and device ejection

Sep 07, 2016

Starting with Release 76.5 the app can eject device media or prepare device for safe removal once a backup is done.

Ejecting what

*Media* ejection refers to ejecting removable storage media from an otherwise fixed device such as a tape drive.

*Device* ejection is a misnomer that refers to preparing a removable USB device for "safe removal". It's the same thing that you can do by clicking on a standard Windows "safe remove" icon in the system tray before yanking drive's USB cable out.

In a true Windows fashion ejecting a media sometimes also ejects a device and sometimes you can also eject media from an external USB HDD (and, yes, this makes absolutely no sense). So certain amount of experimentation may be needed when configuring the ejection.

Ejecting when

When enabled, the ejection is executed when a backup completes in full. That is, when it manages to go through scanning and planning phases and then all backup steps are processed, though no necessarily successfully.

If a backup is cancelled or aborted due to a critical error, then the ejection step is not executed.


This condition can be relaxed so that the media/device is ejected after every run, regardless of its outcome. It can also be tightened to require a *clean* completion, i.e. without any errors.

Sep 07, 2016

Media ejection, the caveats

Microsoft's documentation specifies 4 steps that are required to properly eject a media -

1)  Lock the file system volume
2)  Dismount it
3)  Tell the device to enable media ejection
4)  Tell the device to eject media

Step #1 is a problematic one, because it requires that nothing on the system to have any references to anything on the drive. This includes file indexing software, open Windows Explorer windows, etc.

To that end, it's not uncommon for *device manufacturers* to advise using the best effort in locking a volume - try locking it, but proceed anyway if locking fails. This usually works OK, because dismounting a volume cancels all outstanding references and flushes its write cache. So unless there's an process that is actively writing something to the disk, it all works just as it would when a volume is locked beforehand.

Step #3 is also a quirky one as not all (but few?) devices support it. So the approach here is similar - try and enable ejection, but tolerate a failure if it happens.

Sep 08, 2016

Enabling ejection

Ejection is configured by by adding an override to the job's configuration.

        For how to add a job configuration override see -

Ejection of source and destination media/devices is set up independently, with their INI entries starting with conf.src_eject_... and conf.dst_eject_... respectively. For the sake of brevity the rest describes just the destination setup.


is 1 for "enable", 0 for "disable".


is 1 for "enable", 0 for "disable".


are 1 for "don't", 2 for "attempt", 3 for "require". See "Media ejection, the caveats" section above for details.


is 1 for "always", 2 for "after completed runs", 3 for "after clean runs". See "Ejecting when" section above for details.


To enable device ejection after completed backup runs use:

    conf.dst_eject_device             1
    conf.dst_eject_when               2

To enable media ejection with best-effort volume lock, no ejection prep use and after every backup run:

    conf.dst_eject_media                 1
    conf.dst_eject_media_lock        2
    conf.dst_eject_media_prep       1
    conf.dst_eject_when                  1

EdyJay92 :

Dec 25, 2019

You should add that you have to do this with Bvckup closed :))) there will be probably people like me, that are dumb or too hasty to get the results.

Also, I encountered many "removal vetoed". On one case (3tb hdd removable) I think I have a bad cable that keeps restarting the hdd randomly.

But on the other case, firstly, I encountered "removal vetoed" because I set eject_when to 3 (I thought it was the best, as you mentioned [It can also be tightened to require a *clean* completion, i.e. without any errors.]   and, though, it was clean, no errors, the only error I would get is "removal vetoed", and if I'd run it again after that, then removes it like a charm. - but I didn't like to do a 2nd step so I set it to 2.

And a summary explanation of every conf.dst would really help understand better what you do and what to expect.
I find it difficult to understand especially media_lock and media_prep what they do and what is my best choice. A definition of them would be nice.

This would be my experience with "ejection" :)) and many thanks!

My best setting applied so far:
conf.dst_eject_when                                2
conf.dst_eject_media                               1
conf.dst_eject_media_lock                      2
conf.dst_eject_media_prep                     1
conf.dst_eject_device                               1

Alex Pankratov :

Dec 26, 2019

You should add that you have to do this with Bvckup closed :))) there will be probably people like me, that are dumb or too hasty to get the results.

Whoops. Direct settings.ini editing has long been superseded by the use of _overrides_, which is simpler and doesn't require shutting down or restarting the program. I changed the post to link to the latter.

Emphyrio :

Feb 04, 2020

I have two backup jobs, that are started when the USB drive is connected. I would like to eject the drive when *both* jobs are finished. Is it possible to configure this?

Alex Pankratov :

Feb 04, 2020

If you want to be able to run them in parallel with each other, then I can't think of a way to do it elegantly, no. But if you are ok with running them one at a time, then there are options.

One option would be to chain them together, so that you'd launch the first one, then once it finished, it will kick off the second one and that one will eject the drive. The "kick off" part can be done via a command-line control done via a post-backup script.

See here -
and here -

Alternatively, you can put them into a custom queuing group, start first, start second and then have the second eject the media.

See here -

Miles :

Dec 28, 2020

I am running a pre-backup script to mount the drive and a post-backup script to unmount the drive as described here: .

The only drawback so far is that device tracking is not supported since the drive letter does not appear until after the pre-backup script has run:

The original backup device cannot be located. If you'd like to disable this safety check and force running the backup, disable device tracking by clicking on the pushpin icon in the "Backup to" field in backup settings.

It would be swell if the initial drive letter check could be skipped while still allowing for device tracking.

Alex Pankratov :

Dec 30, 2020

... while still allowing for device tracking.

To what end? I mean, what's the exact use case?

Miles :

Jan 03, 2021

Sorry, Alex; the more I think about it, the less necessary it seems after all; I was just thinking it might be handy in case another device had grabbed the letter assignment before the desired drive was remounted.

Bvckup will apparently not start scheduled jobs (or even their pre-backup commands) if the destination drive is not present, so the drive mounting script has to be run separately beforehand unless I am mistaken.

Miles :

Jan 03, 2021

Just found the solution you crafted two years ago for the destination drive issue here:

Thanks very much!

New topic

Made by IO Bureau in Switzerland

Updates Newsletter
Blog & RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms