@scottalanmiller

Not gonna lie...understood like 3% of what you just wrote.

But hey, I guess thats kinda why I'm doing this stuff in the first place.

@scottalanmiller
Oh so Zimbra does offer HA,

Thats pretty sweet
Thanks!

@scottalanmiller

I would want that 100% of the time I could send and receive emails.

So I would assume I would want atleast 2 Zimbra servers so I guess its just a matter of can 2 Zimbra's share 1 database.

I use to use Postfix so I know how awesome it is at storing emails.

@scottalanmiller

Thanks!

So essentially I would (hypothetically) set up 5 Postfix's and 1 Zimbra.

(Yes I realize this is stupid redundancy)

Or since ZImbra is Postfix backend would I do 6 Zimbra, or 4 postfix 2 zimbra

Hey guys.

Just to learn

What would be best linux install to go with if I wanted to set up lets say 6 email servers (1 main, 5 redundancy) for a linux mail server.

Essentially a DAG Server

Thanks guys.

My mind is jumping to Postfix but would like your opinions.

Hey guys.

We need to automate the running of macros and sending of an email every day (if outlook is open or not) what would be the best way to go about this?

We just started doing this about a week ago, for speed we got it up and it runs successfully when outlook is open but we obviously wanna take that out of the loop of things that could go wrong.

I assume my obvious answer is task scheduler with VB scripts?

Thanks

@BBigford

To add more context

Its actually for employee's we just havent finished migrating them all over to exchange yet, and with so much going on it could be atleast 6 months before the transition is complete.

So we just need the shared calendar today, with the intent that they WILL all be on exchange.

Hey guys.

Can you grant read/write permission using an exchange 2013 mailbox to someone not on exchange?

I can see 100 ways to do it exchange -> exchange, but not exchange -> external

Thanks

PDQ for close to 3 years now, huge fan

@Dashrender said:

@Sparkum said:

Ran out of disk space, what I believe happened is that Veeam was getting ahead of itself creating the backup and the cache just kept growing while the offload was so slow so it just grew and grew then poof.

Unless thats not how it works then nevermind! haha

But ya, definately ran out of space, and I tried a bunch of things, kept failing, deleted the snapshot and poof, worked.

Well that could easily be it. If Veeam kicked off additional backups while the first one was still running, if you have very limited space on the host, that would probably explain it.

You can solve that by limiting Veeam to only allow one backup at a time per VM host.

There was only 1

Was testing so everything was being kicked off manually

@Dashrender said:

@JaredBusch said:

@Dashrender said:

Replication itself doesn't need to involve snap shots though.

You can have Veeam take a backup of the VM to local NAS. Then you can have Veeam, as a different job, replicate that backup over the WAN. That replication won't touch the VM or make a snapshot.

It is completely impossible to not involve a snapshot.

How do you think the backup was made? With a snapshot. And that information is how the replication job would know what needed replicated.

correct, but it's a two step process.

1. create backup - a) create snap b) copy data to backup repository c) delete snap
2. replicate data from repository to remote location

As long as step 1 is done completely locally, you shouldn't have a problem with your snaps.

What we still don't know - and really is important before providing any advice of real value, is why the snaps caused the server to crash - if it even was really the snap that cause it.

i.e. did it run out of disk space? out of RAM(though that doesn't make sense) CPU overload, etc, etc, etc....

One possible story behind the crash - the snap was taken - the copy process starts but takes forever, the local VM host runs out of disk space - VM Host crashes.

But this is only one of many possible situations. In this situation local NAS for repository would solve the problem.

Ran out of disk space, what I believe happened is that Veeam was getting ahead of itself creating the backup and the cache just kept growing while the offload was so slow so it just grew and grew then poof.

Unless thats not how it works then nevermind! haha

But ya, definately ran out of space, and I tried a bunch of things, kept failing, deleted the snapshot and poof, worked.

@Dashrender said:

@Sparkum said:

@MattSpeller said:

For ~200GB of changes you're in the butter zone for LTO5/6. Just make sure if you go with 6 you can feed it fast enough as they work best with a full buffer to avoid running out of data mid write.

I personally wondering if the ~200GB number I'm coming up with is more how Backup Exec does its backups, looking closely I cant fathem why certain servers have the growth they are showing.

You can have nearly zero total size change but files themselves could change drastically internally, so that needs to be backed up.

I'm not sure how DB's work, but let's assume if you change even one bit in a DB you have to backup the whole thing - so if it's a 100 GB db, and you change 1 bit, you have 100 GB to backup now.. just a lame example.

Ya for sure, and we can some "kinda silly" things set up that would need to change like our OMG VIP sql database, backs up as well as does a DB dumb onto our backup server which then backs up again, so the change on our backup server is huge (didnt take that into account in the 100-200GB)

@JaredBusch said:

@Sparkum said:

@JaredBusch Does replication do any sort of snapshot?

Of course it does. That is how all backup mechanisms work.

This is what VMWare shows on the source host when Veeam 9 runs a replication job .

and here is what it looks like on the destinaiton side.

Ya thats just where my concern is.

Maybe what happened with the VM filling up and crashing is something stupid that I could fix with a simple phone call to Veeam, but like every company we have certain servers that cant have downtime during business hours, so if something like that happened on one of our critical servers shit will hit the fan so fast.

@MattSpeller said:

@Sparkum said:

@MattSpeller said:

For ~200GB of changes you're in the butter zone for LTO5/6. Just make sure if you go with 6 you can feed it fast enough as they work best with a full buffer to avoid running out of data mid write.

I personally wondering if the ~200GB number I'm coming up with is more how Backup Exec does its backups, looking closely I cant fathem why certain servers have the growth they are showing.

I've had nightmares about trying to use / fix BackupExec that would scare the underpants off a fully grown sysadmin

Haha ya for sure, I dont think anyone would disagree that it has its downsides.

@JaredBusch Does replication do any sort of snapshot?

@MattSpeller said:

For ~200GB of changes you're in the butter zone for LTO5/6. Just make sure if you go with 6 you can feed it fast enough as they work best with a full buffer to avoid running out of data mid write.

I personally wondering if the ~200GB number I'm coming up with is more how Backup Exec does its backups, looking closely I cant fathem why certain servers have the growth they are showing.

@Dashrender said:

@DustinB3403 said:

@Sparkum 100-200GB per day in changes?

That's a very large Delta if you're trying to replicate those changes off site.

yeah do the math

5 Mb/s = 18,000 Mb/hr (2.25 GB/hr) max. It's unlikely that you'll get max use, assuming 80% you looking at being able to send 1.8 GB/hr. Assuming you close at 5 PM and open at 7 AM, that's 14 hours you can transfer at full speed, 1.8 * 14 = 31.5 GB per night.

Office is 100/100

And ya increasing the line at the store is COMPLETELY an option. Just trying to weigh all my options here.

Additionally I dont need ALL the data replicated everynight.

Certain things like sharepoint, IIS, reportserver, things like that that dont change often could be backed up less often, so long as the data is relevant enough.

@wrx7m said:

Did you ever talk to veeam about why snapshots were crashing your server? Do you have really old/under-powered hardware with super slow hard drives?

Havent talked to them no, its was pretty black and white VM crashed due to resources, delete snapshot and poof it works.

(almost) everything is running off of quick systems, quick SAN's mainly all 15k or SSD

@Dashrender said:

In reading DenisKelley's post and then re-reading JB's post - I suppose you could go for incremental replication at the hypervisor level, but I don't know if that requires a server with a hypervisor on it at the remote location. Be that as it may, it's not a backup, it's a replication of the live system. So you can't go back in time. If the live system gets infected, and that infection is replicated to the DR site, you're done. So again, this is not backup.

How much data are we talking about?

You mentioned that your server crashed (I'm assuming your VM host) because it ran out of space due to snapshots?

Wow - what's your change rate? How much total data do you have?

I don't know how much extra storage you have on that server, but if you're running it out of space because a snap file is there, damn. Sounds like you have a huge change rate going on. Depending on your change rate, you might not even be able to replicate your backups over night with a 5/5, mathematically it might not work out.

A replication of a live system is completely fine, might actually be nice.

We have our onsite backups that go back 4-8weeks so infection isnt really our concern with the offsite, our concern is if we lose the building.

Total data is pretty big. If I was to guess...4TB? plus or minus 1TB (2TB being FileServer)

Change....as well probably pretty big, the biggest part right now (cause of how we do it but it can be changed) is DB dumbs of our SQL, so we would obviously change that, all servers change 100-200GB? maybe more, honestly not sure, DOESNT NEED TO BE EVERYDAY

Talking every week / every month (for less important)

Just plain and simple, whats the least painfull way to get backup if a plane flew into our building.

If our sharepoint site was 3 weeks old, but our POS was 1 days old, we're not doing too bad.

@Dashrender said:

@JaredBusch said:

@DustinB3403 said:

Well he'd be making the full onsite, and seeding to the other (left that part out) with both NAS on premise.

Removing the internet from the picture.

But a NAS to NAS replication is still going to transfer a crapton of data when you do a local full backup the first time after everything is seeded and the NAS moved back offsite.

Replication at the hypervisor level or the VM backup level is needed to provide enough intelligence to transfer replication offsite.

WHAT? why would you say that? and now you're talking more about a continuous replication and probably never doing a full reseed.

and besides, can he even do a hypervisor replication without having a hypervisor in each location?

There will be a server running VMWare at the offsite as well