A cloud is another name for a workgroup. We prefer the word cloud, as Microsoft had a diabolical habit of claiming common names for the sole purpose of interfering with our vocabulary.
We thought we understood the workgroup, but in truth the management of one required magic.
A thin client gui app, by definition, withholds ownership. We can but interact with the Universe. We ever so carefully edge our gems into a cloud app (a thin client), only to find that they now belong to another. We must have faith, and we must learn submission. Our spring of hope bubbles out we know not whither.
I was involved in a great debate over cloud email. These facts of thin clients being known to me, my resolution was to oppose it. However, the management of other people's emails is about as unpleasant a task as one can hope for. Cloud email requires us to manage two lists of the same users: that is about the only drawback from it.
We might think of connecting our workgroup to Microsoft's cloud.
"Let us connect this thing to that thing."
"What they hell are they?"
Proceed with caution, dear reader! What has been seen cannot be unseen!
Our workgroup--our cloud--contains a set of filesystems; but these contain--must contain--files which by no means belong to us. If we have bespoke code, this is likely to be the only code we are interested in; the rest only demands our attention when it gives us trouble.
We consider that a tree has multiple roots. We can therefore start with any directory, give it an identifier, and call it a root; and then we must thoroughly analyse it in the context of backups and permissions.
We aught to maintain a list of backup media every root is to be backed up to; we seem to have work for a relational database, yet.
The rest is no doubt obvious. I, for one, do not intend to spoonfeed you!