cannot meet retention due to lack of restore points

[myrdin]

HI everyone,

this is the problem

- Customer has 1 server he needs to backup every 1 hour throughout the day (so approx 24 restore points /day).
- the set retention period is 8 weeks

since 24*7=168 restore points per week, 1344 restore points per 8 weeks, how can i achieve that retention since i cannot set more than 999 restore points? Copy jobs?

thanks

[Shestakov]

Hi Nick,
It can be achieved by using 2 backup jobs with backup window option.
1344 is a huge number, make sure your customer has enough space on his repositories and avoids very long chaining.
Thanks.

[Vitaliy S.]

What kind of server you're going to backup?

[myrdin]

Hi Shestakov and thanks that is actually a very good idea!

Hi Vitality, those servers are a mix of SQL and Exchange servers. Backup target is a DD2200 which is actually going and performing very well (with only one full i am already getting 10X compression).

[myrdin]

ACtually backing up the same VM with 2 different job, is it going to screw up the CBT? is the CBT linked to the VM or to the Job?

[Shestakov]

2 jobs will not screw it up, CBT compares changed blocks since the last run of this particular job.

[Vitaliy S.]

Hi Vitality, those servers are a mix of SQL and Exchange servers. Backup target is a DD2200 which is actually going and performing very well (with only one full i am already getting 10X compression).

Hmm...what kind of storage do you use to host these VMs? Are you going to use storage snapshots in order no to stress your VMs with frequent VM snapshot commit operations?

[myrdin]

Hi Vitality,

thanks. UNderlying storage is an autotiering with SSD drives, plus we are talking about couple of hundreds of gigs. I have been running those jobs using NDB and no problem on guests.

cheers

[KimmoJ]

Another way to solve it if you need high granularity on the backup is to just set up a job in the SQL server management interface to dump the database to local disk in dumps, diffs and redo logs. This can be done very frequently without a lot of server impact, unless it's huge I guess. A full dump periodically and then frequent redolog dumps throughout the day are probably the most useful combo, in my not so DBA-specific opinion.

Then make sure you echo that storage to another machine or a storage server - can be done cheap or even free with something like the open source Freefilesync (they have a realtime sync variant included). With redo logs you can restore to a very precise point in time, and you don't have to keep flogging the system with VMware snapshots, which are pretty clunky to begin with and really suck performance out of the system compared to something like ZFS snapshots.

That way a daily backup with Veeam is more than enough, you only need that if you have to restore the entire VM. To restore the database, you use the full dump and redologs you have stored on disk somewhere else. To recover from a full disaster, restore the VM first and then restore the dump and redologs.

[Vitaliy S.]

Another way to solve it if you need high granularity on the backup is to just set up a job in the SQL server management interface to dump the database to local disk in dumps, diffs and redo logs.

...or you can use Veeam SQL jobs to backup transaction logs of each database and do full image VM backups once a day.

thanks. UNderlying storage is an autotiering with SSD drives, plus we are talking about couple of hundreds of gigs. I have been running those jobs using NDB and no problem on guests.

In this case you should be good to go.