file server replication and backup from slave server

[lathost]

Hi all! I'm new here and new to Veeam. I'm build esxi nas storage. I have two file servers , both linux. I have master file server and second box is slave. I'm using DRBD to mirror data to slave. All esxi hosts using only master box. So the question: Is it possible to make snapshots backups from slave box? Why asking you.. I just want to reduce load on master.

[Vitaliy S.]

Hello,

First of all you should understand that snapshots are not backups. Secondly, could you please tell me whether you've built your file servers using Virtual Machines or not? If yes, then as far as I understood you've connected your file servers (linux VMs) via iSCSI to the NAS storage, right?

Thanks!

[dellock6]

Uhm, maybe he mean he built a NAS storage made with two linux boxes, replicating each other via DRDB. I've seen this designs in the past, and people hurting themselves badly with them.
About snapshots, with DRDB storage ESXi seen only the active LUN on the master node, so there is no way to request a snapshot on the slave storage from ESXi.

[lathost]

dellock6 is right. File servers are two separate boxes, not VM. So as I understand Veeam access Esxi host to get data? It just can't look into some disk images and grab info from there? why you think we could have problem with this setup? It is the fastest way to make and to sync mirrors.

And yes, they will be connected with iSCSI

[dellock6]

Even if you go for DirectSAN connection from Veeam to the DRDB storage, since the storage itself is exposing luns via iscsi, you would be able to see the same storage configuration that ESXi sees. So, as long as the LUN is exposed from the master node, both ESXi and Veeam will connect here, and in case of a failover, both will connect transparently to the slave node. Unless there is a way to publish a snapshot of the LUN from the slave while the master is serving it to ESXi, but I'm not an expert of DRDB so I do not even know if it's possible.
About my doubts, I've got in years many customers going for DRDB right because "it is the fastest way to make and to sync mirrors". When you start putting some real load on it, I've always seen nodes loosing sync and never getting back, and in one case a complete loss of data. Obviously, it's my opinion.

Luca.

[BigGeorge]

Hi,
You're using the two Linux DRBD server as iSCSI Storage for your ESXi hosts?

If yes you can "plug" your backup server in the iSCSI network (to see with them the LUNs), then you can use the "Veeam SAN transport mode" (backup pulled from iSCSI network directly from your Linux Storage, but using the vmWare snapshot technology.
You cannot use the Linux snapshot (you can use the LVM snapshot at the layer over DRBD, but you can't mount them with veeam).

I've tested the snapshot an veeam backup tech over DRBD on virtual machines environment (for testing purpose). By this way we can achieve the result to have "crash-consistent" backup in production hours without "freezing" due to taking snapshot with "quieshing" mode.
This is (approximately) the environment and the procedure:

• 2 Centos VM with some VMDK replicated via DRBD syncronous, over DRBD (one DRBD for each VMDK) I've configured an LVM volume (that include all DRBD instance), then I've configured the iSCSCI target to publish this volume.
• 2 Centos VM that mount the previous created volume via iSCSI using a Linux Cluster File System.

When I do the backup, to ensure consistency, I make this scripting procedure:

• Quiesce cluster file system on the cluster hosts
• Create a Snapshot on LVM layer in the "storage" vms
• restart cluster file system
• detach the Secondary DRBD (stop replica)
• remove LVM snapshot from primary DRBD vm (the the production env is in original state and performance)
• isolate the secondary DRBD VM (formely VM_DRBD_2) from the master (detach network in vmWare layer)
• setup network, iSCSI and other settings to simulate the master DRBD vm (we do this step to optimize the recovery procedure and backup testing: we need only to power-on the vm in production/test environment)
• taking veeam backup for the VM_DRBD_2
• reconfig V_DRBD_2 to original settings
• reactivate vm network
• reactivate DRBD replica (at this step the DRBD resync the device blocks from primary to slave DRBD vm)

The "tricks" is that the LVM snapshot use the copy-on-write technology and then is immediately to take and consolidate (opposite that vmware snapshot technology) then the freeze time due to "suspend CFS"+"take LVM Snap"+"restart CFS" is <<1 second (and do not crash our app).