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.

@Dashrender said in Does block level sync exist?:

@scottalanmiller said in Does block level sync exist?:

@Fredtx said in Does block level sync exist?:

@scottalanmiller Let me clarify. I want to make sure the "good" backups are copied to the offsite storage. So if the building were to catch on fire or something, and the good copies are destroyed. I would want to be able to restore from the offsite storage. In my case, some of the data was missing from the offsite storage that should have been replicated from the local "good" backup. Not sure what happened, and why it was not copied over, but it did not. I figured there would be some kind of sync mechanism that would have caught that ahead of time, which Barracuda said there is no such sync. That is why I reached out to the community.

We understand. And that's important because clearly your sync failed. It's just that it also exposed the fact that the original backups are not application aware (unless there is no application) so something that you should see as a very, very large issue. If you are responsible for the backups, that is. Otherwise, not your monkeys, not your circus.

You're making an assumption that there's an app to backup - which wasn't 100% clear until this post. As you mention - he might just be backing up file servers - so no app involved - just files to backup.

Even a pure file server is normally accessed. "File server" is a form of "database". A very specific form, but surprisingly similar to a document database. It would be super weird, but not actually impossible, to have a file server that holds files but is never accessed. but once you start accessing files, it's an application doing the accessing and we are right back to where we started. File servers tend to have known usage patterns and accepted backup failure modes, but the issue hasn't changed. It just feels that way. No file exists without an application.

@Obsolesce said in VM replication vs vSAN on two hosts?:

@DustinB3403 said in VM replication vs vSAN on two hosts?:

@scottalanmiller said in VM replication vs vSAN on two hosts?:

@DustinB3403 said in VM replication vs vSAN on two hosts?:

Replication may occur as often as every minute, but you could still lose files or changes within that time span that were never copied to the target.

I think Veeam limits to every 15 minutes?

I don't know as we don't use Veeam replication. I know other solutions can go as often as every minute. But that is outside of this scope.

Some every 30 seconds.

DRBD does it in milliseconds, as fast as the platform can do it.

@momurda said in Building a Basic DRBD Cluster on OpenSuse 12.2:

What is the purpose of 'zypper -remove patterns-openSUSE-minimal_base'
I know what it does, but is it necessary? Does this minimal_base package prevent you from installing certain packages at a later date? Or you just making things nice n neat?

It's been quite some time, but if I remember correctly it interfered with some packages that we needed as the "minimal" blocked adding a bunch of stuff.

I forgot about this topic and found it mentioned in a conversation. This thread was a great resource that never got linked anywhere useful. Now to figure out how to make it more referenceable.

@Dashrender said:

@scottalanmiller said:

@Dashrender said:

I can see doing RAID 6 if you can afford the performance penalty.

Which you would assume that you can if you can wait for a distant node to write as well.

By distant, you mean local, as in the same rack?

Yes, distant meaning outside of the chassis connected over a slow Ethernet link.