@phlipelder said in Use Hyper-V to replicate Linux vm file share: @scottalanmiller said in Use Hyper-V to replicate Linux vm file share: @phlipelder said in Use Hyper-V to replicate Linux vm file share: Hyper-V Replica would work in this situation with a few caveats. There is a 15 second limit on replication cycles. If the VMs are running database/active services this could be a problem. That would be handled earlier in the process by the backup job. If the backup is good, the replication won't cause an issue. If the backup is bad, the replication can't fix it, of course, but will replicate the bad backup. But the only place that this can be addressed is in the backup step, the replication is of backup files, so not at a point in the process where it matters. "Garbage in garbage out" never seems to go away. It's been the bane of our existence since the switch to image/block based backups. :S File backups suffered from this, too. Databases are just hard to back up.

@mlnews Thread resurrected !!! I see, interesting . Regarding Ovirt + GLusterFs my update on this is that did learn glustering and it was easy to perform. I didnt apply it in production or VMs. I did use Ovirt a month ago and it was very slow web ui experience. I should write a thread about my and Gluster.

@JaredBusch I also didn't mind about zerto at the time because my resellers (asked a couple) offered really high prices - but don't remember the specific amount.

@beta said in SW Port - New Server for virtual host - Sanity Check: Oh, one thing I was really curious about too, would it make sense to get an extra drive as a hot spare? Normally with OBR10 and spinning HDD, I'd put every spindle into the array, but since SSDs are going to give me plenty of IOPS and capacity, I didn't know if it is a good/bad idea with OBR5. The rule of "no hot spare ever" for RAID 5 still applies. If you were going to do this, you would do OBR 6. OBR6 can make loads of sense here, but OBR5 + HS does not. But it is up to you, depends on cost and risk aversion.

@dbeato said in JRNL_WRAP_ERROR (SYSVOL): @wirestyle22 You can still do the following as well: http://kpytko.pl/active-directory-domain-services/authoritative-sysvol-restore-frs/ https://blogs.msmvps.com/acefekay/2013/08/28/how-to-recover-a-journal-wrap-error-jrnl_wrap_error-and-a-corrupted-sysvol-from-a-good-dc-what-option-do-i-use-d4-or-d2-whats-the-difference-between-d4-and-d2/ Maybe also move to DFRS instead of FRS, you would only use FRS if it is Server 2003 as part of one of your DCs Possibly in the future but I have so many other things to focus on

@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.