Very good. Fairly straightforward and not at all uncommon.
The specific requirements are being established. And you are quantifying things: 500M daily, cost per 512G, etc..
(Note, full disclosure: not sure about the costs per 512 G of storage. However, I would not be surprised if exceeding that 512 G limit by even 1 byte would result in a charge for 1024 G. Read the billing details to be sure about how charges are calculated and applied. Usually not in the customer's favor. In fact, it is very important to get legal input regarding any contracts offered. Details matter and the fine print may simply nullify responsibilities. Or otherwise absolve such.)
The source database being 280G with daily activity being about 500 M of + or - changes per day - correct? With the database size remaining around 280G - correct? Is it likely that the base database will grow? If so, how fast?
Noted: "any update happens on the source to be updated automatically on the destination daily ".
I understand "daily". However, if the data is transactional and needs to be saved and stored on an ongoing basis then some "end of day" snapshot may not be sufficient. And all lost data reentered in some other manner - if possible.
There are different type of backups as you may already know: full, incremental, differential, and variations thereof.
Here is a link that summarizes the backup types:
Backup types.
The link is provided only as a reference. You can easily find other similar links, discussions, and tutorials. And I recommend doing so.
So if the Windows Server 2019 host fails at noon today will yesterday's end of day backup be sufficient to recover everything? Either on its' own standalone merits or along with some accompanying inclusions of any data changes made this morning? Those morning changes being copied and backed up on an ongoing basis. Does IT have the resources to execute such a recovery? What needs to be done? Documentation, SOP's, notifications, contingencies....
From the link:
"Synthetic full backup
A synthetic backup combines the last full backup with subsequent incrementals to provide a full that is always up to date. Synthetic full backups are easy to restore from, but also do not overly tax the network during the backup itself because only changes are transmitted. There is, however, a processing overhead at the backup server."
Processing overhead - operationally understood. Financially means more $$$.
My view from way afar is that a synthetic full backup may be a solution. Seems to balance the requirements somewhat - there may well be details and other factors that prove that (and me) to be wrong.
Diagram the requirements. Start with something like:
Windows Server 2019 host with 280 G of data =====> daily, end of day full 280 G backup =====> Azure blob host.
However, you do not want to, as I understand it, do a daily full backup of all 280 G. Just the 500 M of changes.
Windows Server 2019 host with 280 G of data =====> daily, end of day incremental 500 M backup =====> Azure blob host.
Where =====> represents the applicable network/communication paths being used. I would include all devices in the diagrammed plan. Any could fail.
You must really take a broader view these days: Your server fails. Building power lost - indefinitely. What if the Azure host goes down, what if the communications are gone, How much does it cost your company per day if data is lost and slow to be restored? What keeps you awake at night?
"No worries" does not apply to IT.
Backups are important and necessary. But not enough. Consider a broader disaster recovery plan that brings all of your IT resources to bear when problems occur. You only need to watch current events & news to know that things can go bad at any time for any number of reasons.
The costs of a disaster recovery plan could be high. Likely less than what it could cost without an operational plan in place and regularly tested. (Common oversight.)
Think about it all, brainstorm, plan. The plan will never be perfect (Murphy lives) but something is better than nothing. And the plan must be able to evolve.
Also: there may be other ideas and suggestions posted. Even to correct some error of omission or commission on my part. I have no problems with that.
So now consider your plan. Put the pieces together, step back, and get a sense of it all.
Keep filling in the missing pieces. I think the appropriate tools will reveal themselves.
Facebook
Twitter
Instagram