@thwr said in DCs out of sync:

@Dashrender said in DCs out of sync:

@thwr said in DCs out of sync:

No substantial changes have been made during the last couple of weeks. Just a few new users and password changes plus maybe 2 or 3 new machine accounts. Some clients and servers now refuse to authenticate users during login due to the well known "trust could not be established between..." error.

Where you still getting those errors after you powered down the broken DC? I'm guessing not since you moved forward with the install of another DC.

Nope. Only "missing that other DC" errors now, which is fine. I've got some crappy internet connection (free WiFi in the train, next to no 3G/4G signal) here and can't check the current state. but it was fine half an our ago.

OK, reading your OP, it seemed that you were getting those errors after turning off the broken DC, but since you're not - seems like you found a good solution.

@scottalanmiller said in SQL mirroring advise:

@Ambarishrh said in SQL mirroring advise:

@scottalanmiller said in SQL mirroring advise:

@Ambarishrh said in SQL mirroring advise:

@scottalanmiller said in SQL mirroring advise:

@Ambarishrh said in SQL mirroring advise:

@Dashrender said in SQL mirroring advise:

Are the two SQL servers sitting side by side? If not, shared storage and low latency for it's use would be super expensive.

Though I do wonder how their DR plan works if there isn't a cluster for the DB, what purpose does the second server serve? Warm spare?

Yes the servers are side by side, basically just sits there, and when a new site is created on SP side, run the script which mirrors the new DB created on server 1 to server 2. Eventually they were planning to introduce the witness server once our testing is complete and then enable auto failover. The downside here is that someone need to manually run the script for db mirroring of new databases

So the big thing here is that the databases are not mirrored, just the framework (schema) is at creation time. Very different from mirroring or clustering at that aspect level.

Yes, we've told them this won't work and asked them to look at a clustered setup. Since the licenses are already in place and is SQL standard no option for Always-On. I want to know what would be the drawbacks for the clustered setup, as for sure there are some more advantages on Always-ON compared to the clustered setup.

Won't work... for what? What's the end goal?

Won't work: Current stage its 2 separate DB servers and mirroring needs to be done by executing a script whenever there is a new db is created by SP.

End Goal: A fully automated failover setup giving high availability for the SharePoint solution

What they are doing is unrelated to their end goal. How does mirroring database creation help with failover. There isn't even a first step in preparing for a failover here. What is going on is totally something different.

Exactly what i was asking earlier.

@FATeknollogee said in XenServer: Backup & Replication:

I assumed we "are" talking about 7.0?

Yes, it works on XS7.

@DustinB3403 was running into the same issues I was on 6.5.

There is dicsussion that some other process is changing it back, but we have not started to troubleshoot that. (I no longer have any XS6.5 boxes here.)

@stacksofplates said in Replication cable:

Finally took some time and Gluster is running on both nodes. I get local speed and network replication :).

Nice

@Ambarishrh said in LAMP replication to DR site:

How about setup MySQL replication to remote site and then enable MySQLdump local backup on the DR site as well with increased frequency than daily ( may be twice a day). This way we have an up to date/latest copy and in case let's say there was a drop table command on master, and primary site failed, I can still switch to secondary, use the latest mysql backup to restore and make it up and running.

Yup, that's what I would do. Get HA and DR all in one setup. Have it take backups 24 times a day if you want. The impact is pretty much zero.

@Danp That might be exactly what I'm looking for. It certainly seems like it is.

I'll have to test it tomorrow when at the office.

@coliver said:

repadmin /replicate DC1 DC2 dc=domain,dc=com

So I have have limited success.. but success was made. I the user I created on the other end,.. is now on the local AD.

I'll look at this more,.. but think it's otherwise solved.

@JaredBusch said:

@DenisKelley said:

If you are trying to use Veeam, the standard setup would to have a server running a second copy of Veeam B&R at the target site. You'll link the two and configure the replicas. You do not need to purchase a second Veeam license to do this, but you will need a running B&R at the DR site.

That was my understanding of how it works, but it has been almost two years since I talked to Veeam about it.

With what I've seen with v9, you now can do full failover scripted ahead of time to make it a bit more turn-key during a disaster.