2

I just got a new 1TB USB SSD, to use as a backup drive. I need cross-platform compatibility and durability. I've used LUKS+ext4, and it seems both reliable and well-established (i.e. long-term support is likely, which is a must for me).

Unfortunately, this seems less than convenient on OS X (there's no open-source ext4 driver, as most people know). My current setup is to have a Debian VM on VirtualBox, set up to intercept the external drive at the USB level (VirtualBox can expose USB devices to guest VMs).

I have this working, and can then SSH into the VM, but it's not the most convenient. If I'm just dumping stuff there via rsync -av -e ssh it's okay, but browsing through files on sshfs is not what I'd call ideal (sshfs is notorious for hanging & refusing to unmount on dropped connections, for example).

Has anyone else tried something like this?

Related: Cross Platform GUI-compatible Encryption (but I don't care about GUIs)

  • you could try this: use ExFAT for the disk it self it's native on Windows 7 and greater and it is there on OS X and also on Linux you have drivers for ExFAT (since i don't have a linux right now i can't test how well it works on linux) and the save a encrypted disk image on it and store your actual backup data inside the image file – konqui Aug 11 '16 at 18:24
  • On MacOS just buy the driver from Parallels. – Thorbjørn Ravn Andersen Sep 23 '18 at 17:08
1

I've done the Linux VM solution like yours for years on multiple platforms. But different, and depending on the specific use case, much better. (I've tried your method as well. Too many problems, particularly with USB passthrough.)

Here's what I do, roughly, using VirtualBox (not a step-by-step guide but should be enough to get you going):

  • I don't attach the external volume via USB intercept; I create a raw VMDK of the external drive first. This requires some script magic: You have to 1) Make sure VM is powered off. 2) Delete the VMDK metadata file. 3) Detach the virtual storage controller dedicated to the USB drive. 4) Create a new raw VMDK file for the USB drive [this part is challenging since the physical location changes; I use a script parameter to pass it in to the script]. 5) Create a new virtual storage controller for the VM. 6) Attach the raw VMDK to the new storage controller. 7) Start the VM. The drawback to this approach of course, is that the USB drive and the VM are tied together for the entire session of the VM. If you unplug the USB drive while the VM is running, it will never be valid again (until you shut the VM down and run the script again). But the benefits are huge: A) It works flawlessly, unlike buggy USB intercept. And B) The performance is near-native [since the host is handling the low-level device I/O], which you can't get with USB intercept.
  • I set the VM up with two network adapters: 1) NAT with DHCP for regular internet access from within the VM, and 2) Host-only with static IP for host-to-VM access. You could also just have one bridged adapter, but I've found that this approach is more ideal, as VM internet access is not tied to any one adapter.
  • I set the VM up to share folders via SMB. In my case, these are encfs mounted folders.
  • I then mount folders on the host, mapped via SMB to the guest.

The performance is pretty decent. SMB over gigabit ethernet between real hardware has a theoretical maximum of something like 120 MB/s (there is a specific number max but that's close enough for this discussion). You probably won't get that high in host-to-vm SMB traffic, even using virtio adapter with no bandwidth limit. On my fastest hardware, I've seen at best around 70 MB/s sustained. But my hardware isn't super fast, you might do better. (Although the USB and spinning disk in your solution will be the limiting factors.)

I would not bother with sshfs. The overhead is severe and throughput terrible. The only benefit to sshfs is when mounting over an unsecured network. Host-to-vm exists completely within your own computer and is therefore as secure as it gets, you don't need encryption, and the lightest-weight network protocol you can get is ideal. (SMB isn't exactly lightweight but it and virtually all hosts support all the remote file actions you could need.)

The solution I've outlined seems complex - and is. But if you document the successful process, it's trivially easy the second time. I have all this scripted in both the host and VM, so it's nearly automagic for every session, and easily set up for new hosts and/or VMs. And it's a very nice and seamless solution for daily use.

Hope this helps.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .