Backup copy job settings Help

[Darkzadow]

Hello,

I am looking for some help on setting up a backup copy job settings.

I have repository 1. I want to keep a month of daily backups on this repository
On repository 2. I want to keep monthly full backups for 2 years (so 24 full backups)

I think I can use the following backup copy job settings, but waiting a month to find out it is wrong is longer than id like. So im asking you fine folks for advice.

Proposed settings:
Main job - 31 restore points, incremental, synthetic fulls on saturdays, to repository 1, schedule - daily
backup copy job - periodic, retention policy 32 days, GFS settings - Keep monthly backups for 24 months, schedule run -1st of the month, to repository 2

I think this will do what is required, but I am not sure about the settings, I was also thinking I could change the retention policy on the backup job to 1-2 points and that would be an easier setting.

Reason for this is that Repository 1 is local, and Repository 2 is a windows NAS, with dedup enabled, in a separate DR building

Let me know what you think.
Thank You

[Mildur]

Hi Brandon

Main job - 31 restore points, incremental, synthetic fulls on saturdays, to repository 1

I recommend to use retention type "days". With "days" retention you can specify the exact days you need the restore points.

I think this will do what is required, but I am not sure about the settings, I was also thinking I could change the retention policy on the backup job to 1-2 points and that would be an easier setting.

Primary backup storage is normally placed as near as possible to the production environment for fast backups and restores. You probably want to keep more restore points than just 1-2 for the fast restore. I normally recommend to keep at last 2-4 weeks on the primary storage. But it depends on your backup strategy how many days back you need to have faster restores.

backup copy job - periodic, retention policy 32 days, GFS settings - Keep monthly backups for 24 months, schedule run -1st of the month, to repository 2

I suggest to write daily backup copies. Let's imagine we have end of the month and something happens to your primary building. Let's say, production server and backup server burned down. You get replacement hardware, but the only backup you have is 30 days old from the beginning of the month. Can your business survive a data loss of 30 days? 30 days of data loss will be really expensive for most of our customer.

Reason for this is that Repository 1 is local, and Repository 2 is a windows NAS, with dedup enabled, in a separate DR building

May I ask, is there any immutable or air-gapped backup storage involved in your design? I'm talking about backup storage which protects your backups against ransomware attacks. Options include:
- Hardened repository (immutable)
- Object Storage (immutable)
- Tape (airgapped)
- Rotated disk drive (airgapped)
- Cloud Connect with Insider Protection

With local storage and NAS (shared folder or iSCSI repository to a windows server), an attacker on the backup server can simply delete all backup files.

Best,
Fabian

[MarkBoothmaa]

If you have a windows repository I'd recommend going ReFS if you haven't and disable De-Dup as this can cause issues when its running it's optimzation.

[Darkzadow]

Hello,

Thank you for the replies.

I will change the backup job to daily. A 30 day restore would not hurt my machines since they run mostly live production control so rely on live data. SQL backups are being evaluated separately from this backup session.

The air gapped settings are currently a separate NAS that copies the DR NAS once a month and drops offline (the tape server died and is waiting on replacement), and azure blob storage starting next quarter.

As for REFS. Does REFS do a separate space savings mechanism? The 24 monthly full backups will be large (75 servers, 60gb to 500gb average size) not including the SQL data. Other backups from other departments will be targeting the same DR NAS and they were factoring in Dedup for space.

Thank you,
Brandon