VEB 1.5: Eject removable storage & no need to unplug

[veego]

Hello,

when I first learned about the new VEB 1.5 feature to eject USB backup media after the backup has completed, I thought it to be a very nice idea. Taking a second look, however, I was somewhat disappointed about the "one way" implementation (no built in way to recover the drive again, so this option will always require some manual user intervention after the drive has been disabled). But, as disappointmend sometimes is a good motivation, I eventually came up with a way to overcome this limitation - it works like that:

• VEB is installed and configured to run a backup whenever its backup device is being connected (no other schedule) and to eject it when completed
• A small script (just eight lines of code) with the ability to reconnect&restart the ejected drive is being created and scheduled with Windows Task Scheduler (WTS)
• Now any appropriate combination of WTS triggers can be used to start a backup by just spinning up the USB drive and thus causing VEB to start a backup and to subsequently eject the drive again

On some of my own computers. I run this scheme now for several days - and it works like a charm. What's best: Being able to use all the scheduling power of WTS, no manual tasks whatsoever are required (very important for most of the users I know), but still the backup device is inaccessible most of the time (except the few minutes when a backup job is running). This is very welcome in ransomware bothered times. And suddenly, the new VEB feature makes sense

I compiled a short PDF tutorial on how to do this, but I'm not sure about an appropriate way to share a PDF document with this forum. Any recommendations on this?

[Dima P.]

Hi Daniel,

That sounds totally awesome! Please share the pdf via any available cloud hosting (OneDrive or GoogleDrive or any other works). Just in case you have a personal blog – link is also welcome. We will review it with the whole team.

[veego]

Hi Dima,

thanks for your kind reply. Please find the document here:

https://www.dropbox.com/s/cyvubshw9i667 ... 1.pdf?dl=1

Any feedback is welcome

[Gostev]

From what I remember, we planned and even implemented the option to auto-mount, but mounting did not work reliably enough for including this feature into the release, and the issue was not due to our bugs (there's very little code required anyway). May be Dima can provide more details on what exactly did not work.

[veego]

Hi Anton,

thank you - I'm glad that implementing this kind of feature is taken into consideration by Veeam. Yes, handling USB devices can be annoying, but I found my solution to be very reliable till now. Of course I was only able to test a very limited number of OS/USB controller/USB drive combinations so far.

By the way: amazingly, the MS tool I use (devcon.exe) is available as source code:
https://github.com/Microsoft/Windows-dr ... tup/devcon

Maybe you can get some suggestions there how to get the reconnect more reliable.

[Dima P.]

Daniel,

Thanks for sharing, and additional kudos for the very detailed instructions. I've easily set a lab on my home computer to test this approach (literary took less than 5 minutes).

[Gostev]

Maybe you can get some suggestions there how to get the reconnect more reliable.

Well, I have noted that even your own scripted solution does enable/disable with this tool not just once but twice, so I am guessing you are very well aware what I am talking about when I say this does not work reliably and for the same reason, I highly doubt its source code contains hints to the reliable approach

Don't get me wrong, your solution is totally fine for a custom script and should work most of the times, but our quality standards (aka "It Just Works") don't let us rely on workarounds such as "do it twice, just in case" in the production code...

[veego]

Well, I have noted that even your own scripted solution does enable/disable with this tool not just once but twice, so I am guessing you are very well aware what I am talking about when I say this does not work reliably and for the same reason, I highly doubt its source code contains hints to the reliable approach

Of course you're right about the script doing the disable/enable stuff twice - but this is rather not due to some "let's do this twice to be sure it actually works at least once" approach, but much more because that's how the tool works:

• After having been ejected manually or by VEB, the drive in in a kind of "intermediate" state: physically connected, but logically ejected
• The first "disable" makes sure that the drive is in the desired state. If the "Eject" process (done by VEB or manually) did complete successfully, this is in fact unnecessary, but it also doesn't hurt. If the drive is not ejected at all but properly connected, the script won't even get at this point, but exit prior to that.
• The first "enable" puts the drive in a state called "Enabled on reboot". It will NOT spin up in this state, but it's ready to do so.
• The second "disable" causes the drive to get into the "Disabled on reboot" mode. In this mode, the drive will NOT restart, even if you reboot the OS
• At last, the second "enable" puts the drive into the desired state "Enabled". The drive spins up and is ready to use.

To follow this, just run the script manually and take a look at the (rather verbose) output of devcon.exe. It's always the same procedure, and the drive NEVER spins up after the first "enable", so there's no trial-and-error here.

It's a somewhat cumbersom but nonetheless very reliable process as far as I can tell by now, but to be honest, I've got no idea why the tool is designed to do it this way

[wilson]

Just stumbled on this thread but aside from the last post in this thread has the newest version of Veeam End Point made this a workable option yet?
It would be nice if it disconnected automatically at completion of the scheduled job and then auto reconnected for the next scheduled job because that would be a perfect solution.
I hope their development team can pull this off soon.

[91gsixty]

Could the EBR just not Offline the drive or have the same feature as its big brother and have a script before and after job optoin.

EG. Powershell Script
Before job
"select disk 2", "online disk" | diskpart

After Job
"select disk 2", "offline disk" | diskpart

[Dima P.]

Hi guys,

The possible enhancements are still in discussions. We’ve tested several ideas (including proposed) and realized they are not 100% stable. Still investigating.

[Hariseldon1]

I wish to join the quest for "ransonware proof" backup solution!

I humbly offer up a "devils advocate" thought to examine the counter response to this counter response.

FACT = True, "manually unplugging + manually replugging" is annoying when using USB to store backups.

I accepted this annoyance because it provided a "physical firewall" between my backup data stored on USB flash [albeit unreachable because VEB 'ejected' the USB media].

However, you say there is software to re-plug usb flash without manually reseating?

Surely you can see some whizkid will redesign their ransomware to first scan for history of "VID" numbers.... perhaps ransonware will run first in background to learn your habits... and when it sees a pattern of eject/reload VID, then it could use your handy tool against you.

What is stopping ransomware from software re-plugging your usb stick for you, then encrypting your whole system + your whole backup data?

Seems to me:
1st best only answer to "ransomware proof" backups has to be physical separation from backup data
2nd distant best answer is restriction of permissions to access backup destination
3rd last resort answer is attempting to prevent execution of unauthorized code

I want an eloquent solution as much as you do! I love that tool you use! Your sharing this tool has opened my eyes to how a programmer (which I a not) would use a software tool to re-plug my usb flash drive I left attached.

Am I wrong?

[Misterb]

Hi... old post, but Ransomware is still a hot topic! Just want to share what I have done to bypass some concerns with USB drive (Using Backup and Replication 9.5) but can apply to VEB as well.

I am using a backup schedule. When done, it safely ejects the drive using a script after the job (using an utility RemoveDrive.exe).

All my USB drives are connected on a USB3.0 hub (5 drives of 5TB each). To make the drives Offline, I am using a smart outlet with a timer that turns OFF the hub at the end of the day. (I know all my backups jobs are done by this time.) So all the drives can't be turned ON again by any script, even if Windows is rebooted, the drives are not visible.

Then, on the next backups schedule, I make sure the drives are turned ON again by turning ON my hub with the smart timer... wich makes the drives available again in Windows.

It works pretty well! Of course... If a backup job (for any reason) is taking longer than the timer is set to shutdown the hub... I will have an error. But I have enough buffer so it never happen.

That the way I found to have OFFLINE backups. I also have a Linux repository, an offsite repository and a DR site with replication. I hope that way... Ransomware will not win over me!

Thanks for reading... and sorry for my english... french canadian here!

Ben

[govi]

Hi Guys,

That's very interesting topic, when i saw this option "Eject removal storage once backup is completed" in Veeam Agent for windows, i was wondering if there is any way to get this external drive connected again without any user intervention. I have similar scenario in my office that backups are done on external hard disk(not longer the case, we choose different option now) but problem what i have seen with external drives are user most of the time they forget to connect external hard drive and backup never runs or it fails.So mostly user chooses to keep external drive connected all the time to docking station so that they don't need to remember connecting drive every time and i think keeping drive connected all the time which has backup files is big risk. In case laptop/desktop hit my ransomware and external drive is still connected to laptop and that particular drive will also get hit by ransomware virus and we end up with nothing. Having backup data but of no use.

I am not sure if new version does similar job like, connecting hard disk automatically when backup job is about to run and once job is completed its automatically ejects the external hard disk.

Somebody pointed out correctly that bad guys learn the pattern how USB connected and disconnected and they might use same tool to attack on system.To overcome this, i think (just opinion) we can use backup encryption which is available in latest version of Veeam Agent for Windows. I am not sure how backup software works in the background when it writes increments on external drive(meaning Veeam decrypts the previous backup and checks for the content and writes the new increments? ) so if Veeam decrypts the backup, then our problem remains the same. Since attacker will use this opportunity to encrypt the backup and that backup will be of no use. If above case does not hold true then script to connect external drive and Eject External drive+ Veeam Encryption will save lots of IT guys time and data.

I have been challenged to do the remote users backup who never visits head office(offshore guys), without any decent internet speed i cant think about cloud, one drive for business option. Since this will never work due to bandwidth. So option left with me is to use external hard disk but again there is problem, that most of the time user never bother to connect external hard disk, may they are busy during backup run and external hard disk is at distance(just lazy guys). so i was thinking to use SD card (128GB should be sufficient), just plug into laptop all the time(most of the laptop has SD slot now a days). so when backup schedule is about to run, it triggers the script and SD card is connected to laptop and backup process starts. As soon backup is done, script ejects the SD card(logical eject).

Only problem i see is that if laptop is stolen or lost then we lose the backup of that laptop+ laptop. Again we end up with Nothing.Any more inputs for this problem?

Thanks,

Govi

[govi]

Hi,

Do any one has this pdf file? i am not able to access the pdf file, probably its already deleted by uploader

Thanks,
Govi

[govi]

Hi Dima,

Could you please share the pdf version of document which was uploaded?

[nwsundma]

Daniel,

Is the Veeam_USB_Backup_V1.pdf available? Can you re-post or PM me and I will give you my contact info.

Thanks,
Nathan

[orders]

Daniel,
Ditto....really need this option for my 'lazy' users
Is the Veeam_USB_Backup_V1.pdf available? Can you re-post or PM me and I will give you my contact info.

Thanks,
RJS

[Dima P.]

Hello folks,

Unfortunately the pdf was shared by our community member and we do not have access to mentioned document. However, I do remember that we've tested the described approach and it was not working stable. Cheers!