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 changing settings in the job's configuration file.

        For how to find and edit job's settings.ini see -

Ejection of source and destination media/devices is set up independently, with their settings.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

New topic

Made by IO Bureau in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms