Seeding from CoLo (backup to disk)

[ekisner]

Hi there,

Having just replaced my backup storage, I must now begin the long process of doing full backups to the new storage. As the old storage outright failed, I can't drag the files across and re-scan.

Is it possible in some way for me to do an initial backup pass via replicas at my CoLo? The WAN can handle the traffic no problem, the goal is to keep load off of the production storage array.

[veremin]

What backup mode are planning to use? Is it Reversed incremental by any chance? Thanks.

[ekisner]

Afraid not... otherwise I'd restore from tape and call it good. We use incremental passes.

Although, would that work? I'm dreading the initial pass on the file servers. Our storage array REALLY doesn't like deep backup passes (500 to 750ms of storage latency on full passes... painful.)

[veremin]

In this case you can back replica VMs up and use resulting backup file as a seed for backup job.

However, initial incremental pass will consume the same space as active full backup does and probably will take similar amount of time.

So, there are no obvious benefits in this approach.

Thanks.

[ekisner]

Darn. I'll just queue it up over the weekend, we've a light staff workload on the weekend and file servers are not going to impact any public-facing services. Will temporarily edit the repo down to a single task at a time to avoid too much thrashing on the storage array.

[veremin]

Hmm, what kind of backup storage you have that cannot cope with active full backups? Does it host only backups or there is other activity taking place on it? Thanks.

[ekisner]

It is hybrid storage.. it runs fantastically fast for increments but once it has to hit the spinning disks the performance takes a nosedive pretty quickly. As it is production storage it has a pretty diverse workload on it.

[veremin]

Are you using storage device as production datastore and backup target?

I'm wondering because this is not considered the best practice - should something happen with underlying storage, you will lose both production data and backups.

Thanks.

[ekisner]

No the target is a traditional spinning disk array, with a bunch of large disks on it. Our bottleneck is always source, generally around 95%.

[veremin]

Which means that the job spends most time reading data from production datastore. So, to speed up performance it might be worth looking at source (not at target) side. Thanks.

[ekisner]

Right.. which is why I was wondering if I could seed from my replicas. They are stored on different storage where the load would be moot.