After scouring countless sites and articles, only thing that could fully read the drives was UFS Explorer. $700 later and many, many crashes, we are starting to have a reliable process of recovering the data. We have to use UFS Explorer and recover as raw disk images. Then attach those raw images to new VMs manually. Then do a Windows recover to each one.

@syko24 said in SAMIT: Why You Can't Share QuickBooks on Google Drive for Mutiuser:

@scottalanmiller said in SAMIT: Why You Can't Share QuickBooks on Google Drive for Mutiuser:

@syko24 said in SAMIT: Why You Can't Share QuickBooks on Google Drive for Mutiuser:

There is a product out there called QBox that allows you to lock and sync the file with multiple locations. The downside is that remote users can only access the file when the local users have closed out of QuickBooks. Kind of a neat product but again not ideal when you need multiuser access all the time. The best solution in my opinion is an RDS server with the QuickBooks data file stored on the RDS for best performance.

As the QuickBooks desktop products seem to be coming closer and closer to an end, I agree that the online version is likely the best way to go. Part of the problem is that users have been using the desktop version for so long that the online version becomes very foreign to them and most want to return back to the desktop version.

https://www.coraltreetech.com/how-qbox-works

Yeah, that's not multiuser but rather "rapidly changing and coordinated single user". Could be a useful solution for some, though. You can do this with most products. NextCloud for example.

From the use case I've seen that is correct on being a single user product. I did watch the video on the link I posted and it does look like you can still do multiuser as long as the users are all on the same network. The remote user can only access once all the local users are out of the file and it has done it's sync. The file locking is automatic as well which is nice. It basically prevents the outside user from accidently overwriting your changes.

Sure, you can always bypass the sync and do local multiuser, but the humans have to manage that.

Examples in known open source worlds...

If you run ProxMox with DRBD on the Debian (host) layer, it's RLS assuming ProxMox has local disks.

If you then make that block storage available over the network, it becomes a SAN (a traditional / physical SAN.) A SAN with replication for resiliency.

If you run ProxMox and make a VM of Ubuntu and in that VM install DRBD it may or may not be RLS depending on where the host is getting its storage from for that VM. To the VM it will appear as if it is RLS, but we really don't know unless we check the stack. It's just the replication piece here.

If you then make that DRBD block layer in the VM available over the network, it becomes a vSAN.

@scottalanmiller It makes sense they can't because of the nature of their static Database.

@Fredtx said in SAMIT: Should You Still Be Using Disk Partitions:

In a Windows world, it seems it would be better to create a Storage Space, because it gives you the flexibility to extend the storage instead of having to add/mount another virtual drive if you were to run out of space.

Exactly. Same logic applies universally, always best to have that flexibility on your platform. It has no real overhead, but protects against the unknown.