Your thought process makes complete sense, but would lead to a very very rambling series of possibly quite disjointed answers if I followed my training and answered point-by-point.
It is not quite this simple, but most of us can think of two types of "Backing up Atlassian Cloud"
- Atlassian back up all their Cloud systems, regularly and frequently. These backups are designed for them to get all the affected Cloud systems back in service as fast as possible after a wide-scale failure. These backups are largely useless for individual clients - they're aimed at "whoops, we lost pile of disks", not "a single client system did something odd".
- Atlassian Cloud systems all have an option for "download a current copy of me". That's a single copy of the current system, needs you to store it, but is entirely yours.
Given that framing, my answers are a lot shorter:
>there’s no real value in local back-ups as the content of our site is backed-up on Atlassian cloud servers. Is this true?
Not true. Depends on what you want the backup to provide
>if there was a catastrophic loss of data locally to our instance,
Atlassian would restore from their backups, and keep you involved in what was happening and why and telling you when it would be back
>would we be able to restore that data using the Atlassian back-up?
No, that's where Cloud is "software as a service", Atlassian is responsible for restoring the data with their backups.
>local back-ups, what is the process of restoring from these back-ups
your "local" backups can be uploaded directly into a new Atlassian Cloud system with a low amount of fuss (set up a new one, tell it you have an import file, might have to faff with some user settings). Or you can import the backup into a Server or DC system. Bit more faff, but the data is totally transportable.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.