@scottalanmiller said in Does block level sync exist?:

@Fredtx said in Does block level sync exist?:

This design is "supposed" to adhere to the Backup 3-2-1 rule, but I guess technically it does not since the barracuda appliance (where local backup copies of servers resides) is replicating to another appliance at the block level. It's only hoping all the data is copied to the offsite storage.

If it was replicating for real, it could be verified with checksums. Everyone else that does this can do that.

The way I've been told their checking this is by: "Checking the metadata/replicated metadata/local binary data/replicated binary data" between the local appliance and the offsite appliance that it's replicating to. So far, we are on day 21, and the verification is not complete. I'm probably past the point where this needs to be escalated at a much higher level since this could have been data loss.

@scottalanmiller said in Does block level sync exist?:

But why do you have them for backups?

This is the vendor our parent company has been using for some time, and seem to think it's a good product for them to use it for so many years. I mentioned the flaw to upper management during our monthly meeting last week. Director of IT said to let him know if he needs to escalate it. I'm trying to get our divisions backup process in order, and looking at how everything is done, and why is it being done like the way it is, and if it's even working like it's supposed to.

This design is "supposed" to adhere to the Backup 3-2-1 rule, but I guess technically it does not since the barracuda appliance (where local backup copies of servers resides) is replicating to another appliance at the block level. It's only hoping all the data is copied to the offsite storage.

@scottalanmiller said in Does block level sync exist?:

@Fredtx said in Does block level sync exist?:

Block level synchronization would not be possible here as the data is compressed on the receiver but not the sender and the appliances are receiving data from different senders; the blocks would not look the same."

That would cause some amount of problem, yes. If they were compressing in the right place, though, it would not. This is a design flaw, not a data integrity flaw.

Here's an article on how their replication works. How offsite replication works barracuda backup

It says:
"When data is transferred offsite, it is further deduplicated by checking to see if the file part already exists on the offsite replication destination. If the part does not exist, the part is compressed, encrypted using 256-bit AES encryption, and transferred to the replication destination. If the part already exists on the offsite replication destination, the part is simply dropped and not transferred offsite."

From what I see. The backup (vm and agent level) of the servers to the Barracuda appliance (local server linux box) is application aware, but the offsite replication is not.

We use Barracuda backup, and use offsite replication for each of our sites.

I found a discrepancy between the backup appliance and the replicated storage. Some folder/files had not replicated from the appliance even though the Barracuda console says it's been replicating successful.

I've been working with barracuda support for several weeks on this, and they have not given me an answer as to what happened, and why the data was not the same. Their running all these tests to check the integrity of the data such as checking the metadata/replicated metadata/local binary data/replicated binary data.

This check has been running for several weeks, and I asked if there is technology available that could synchronize the data between the appliance and offsite storage. Here is their response " Block level synchronization would not be possible here as the data is compressed on the receiver but not the sender and the appliances are receiving data from different senders; the blocks would not look the same."

A few questions on this.

1. Is this statement true?

2. If it's not true, what is the solution here?

3. If it's true, how do you check the integrity of the data on the backup appliance that is being replicated to offsite, such as another site, or cloud?

My concerns is if this was a major disaster recovery situation such as the building catching on fire, we would be dead in the water. Especially if those files/folders were sensitive data.

Maybe there's a better way to do this. I'm all ears.

@scottalanmiller It's amazing how different types of technology has been around for some time, and people act like some of this stuff is new. Like touch screens for example, everyone was so amazed at them, yet they had been around for years in grocery stores. lol.

@Pete-S That's what I ended up doing. Thanks!

I'm building a new VM on a VmWare host to replace a 2008 server. The 08 VM has 2 virtual disks each mounted with a drive letter (C and D). Would it be better when creating the new VM to instead create 1 virtual disk, and divide it into 2 partitions (C and D)? Thoughts?

My manager (IT Manager) messaged me a screenshot of speedtest.net results from one of our DC's that showed there is 33 ms ping times, and that I should look into this. I login the DC, pull up command line, ran a continuous ping to 8.8.8.8 with solid 3ms ping times. I sent him a screenshot of the command prompt and said ping times look solid to me, and speedtest.net does not give accurate results of network latency from a computer as the built-in ping utility from windows.

This is basic troubleshooting, and is just sad.

@JaredBusch said in Multiple Tombstoned DC's:

Mesh of multiple locations like you have is simply asking for crypto to hit all the things.

Exactly what I've been telling them.

My colleague is saying we should have all the sites connected via a Mesh topology. That's 11 sites, and I feel like that would be too much overhead just for AD. Also, that would also decrease the network security by connected branch office LANS together via site vpn.

I was thinking of having a Hub And Spoke topology to our main site, especially with the fact that our main site handles radius authentication for all the branch offices.

@dbeato said in Multiple Tombstoned DC's:

I would just remove that site from being in Active Directory sites and services entirely.

What would be the effects if I remove that site from ADSS? Would it still be able to have an inbound rep parter?

@PhlipElder said in Multiple Tombstoned DC's:

@Fredtx said in Multiple Tombstoned DC's:

@notverypunny said in Multiple Tombstoned DC's:

@Fredtx does the isolated site still exist in Sites and Services? What's the plan for that location if the ideal end goal is to have the vpn tunnel down and no site to site connection? (apologies if this was already covered)

Yes, the site still exist. I'm just confused as to why the KCC is adding the connection to the link when there is no network connectivity to that site. From my understanding, the whole purpose of the KCC is to create connections with the best paths, which this one would NOT be the best path since there's no network connectivity.

Is the defunct site's subnet set up in Sites? That's what is going to need to be changed or removed.

Yes, it's setup in Sites with the correct subnet as well.

Also, I see all the sites are listed in the Sites/Inter-Site Transports/IP/Defaultipsite link properties. Is that normal? Highlands (defunct site) does have the appropriate subnet configured as I mentioned.

See below

@notverypunny said in Multiple Tombstoned DC's:

@Fredtx does the isolated site still exist in Sites and Services? What's the plan for that location if the ideal end goal is to have the vpn tunnel down and no site to site connection? (apologies if this was already covered)

Yes, the site still exist. I'm just confused as to why the KCC is adding the connection to the link when there is no network connectivity to that site. From my understanding, the whole purpose of the KCC is to create connections with the best paths, which this one would NOT be the best path since there's no network connectivity.

@PhlipElder said in Multiple Tombstoned DC's:

@Fredtx said in Multiple Tombstoned DC's:

@PhlipElder

Sorry, I didn't mean links. I meant inbound partners. AKA "connections" when viewing in AD Sites and Services.

Yes. That's what I understood to be said there.

If there are replication links there that were automatically generated then at one time the good site's DCs were replicating with the offline site's DCs.

I have demoted all defective sites, did metadata and dns clean up, confirmed replication of changes across all domain controllers.

I promoted the first dc successfully. However, the KCC is automatically adding the site that has no network connectivity, which I can't seem to understand why. This is why the dc's tombstoned in the first place. I guess I could create the vpn tunnel? I would think the KCC would detect there is no connectivity, and add a connection that DOES have connectivity.

Any ideas @dbeato @PhlipElder ???

@PhlipElder

Sorry, I didn't mean links. I meant inbound partners. AKA "connections" when viewing in AD Sites and Services.

@PhlipElder said in Multiple Tombstoned DC's:

Just how much change is there between then and now?

I don't know. It's been 8 months so I imagine there has been quite a bit of changes.

Also, just to confirm. The KCC ONLY creates site links for sites that have network connectivity, correct? My coworker seems to think that the Highlands server was never connected to those 6 sites, but from what I recall, they need to be connected or KCC would not have created those links. Again my theory is someone removed those vpn tunnels, or the Highlands DC was configured at our Fort Worth Hub site, and later shipped to Highlands.

@PhlipElder said in Multiple Tombstoned DC's:

What was happening for ADDS/DNS there anyway that there'd be that many tombstoned DCs? How did authentication happen?

My theory is the vpn tunnels were removed, and nobody checked if there was any kind of dependencies for those tunnels.

Below is the current setup.

The replication disconnection/issue happened at Highlands with 6 of it's inbound partners. The one's with the strikethrough

FortWorth -Replicates from Highlands
Highlands -Replicates from Toronto , Edmonton, Fort Worth, Nashua, York, Fresno, New Freedom, Oakland, Atlanta, Pewaukee
Toronto -Replicates from Fort Worth, Highlands, Nashua
Fresno -Replicates from Fort Worth, Highlands, Nashua, Toronto
Pewaukee -Replicates from Higlands
Nashua -Replicates from Edmonton, Oakland, Pewaukee, York, New Freedom, Atlanta, Toronto, Fort Worth, Highlands, Fresno
Oakland -Nashua, Highlands, Fort Worth
Atlanta -Replicates from Highlands, Fort Worth, Toronto
York -Replicates from Highlands, Fort Worth
NewFreedom -Replicates from Nashua, Highlands, Fort Worth
Edmonton -Replicates from Highlands, Toronto

@PhlipElder said in Multiple Tombstoned DC's:

Is there a list of known devices that authenticate against those now defunct DCs? Are they still authenticating?

Most likely workstations are still authenticating. I don't have a list

@PhlipElder said in Multiple Tombstoned DC's:

We've done this a few times where the work to remove the errant DCs was way more than flipping the bit, waiting and watching to make sure they don't screw anything up, and then flip the bit back.

Yea, I'm trying to be efficient as well, but also not screw anything up. lol. Especially since the Dc that has the fsmo roles also functions as Radius server for vpn and wireless authentication throughout different sites. I've only been here a month, so trying to get stuff working as it should.