Solved Backup of Office 365 Sharepoint sites
-
@Dashrender said:
@coliver said:
I had the same question you did and was testing it out on a file. It preserved all of the updates just the most recent one was the live copy.
I don't consider that a good solution - especially if there was no kind of notice that there are differences to be merged.
How else would you do it? I can't think of a better solution, one that preserves all the data input during the offline time.
-
At bare minimum it needs to inform you that there is a different version on the server from when you were last online. Then give you the chance to merge things, etc.
Normal users aren't going to understand how to deal with that. Sure they can be made to understand, but they are going to be frustrated none the less.
-
@Dashrender said:
At bare minimum it needs to inform you that there is a different version on the server from when you were last online. Then give you the chance to merge things, etc.
Normal users aren't going to understand how to deal with that. Sure they can be made to understand, but they are going to be frustrated none the less.
What is the alternative, though? And how do you handle notifications and to whom?
-
@scottalanmiller said:
@Dashrender said:
At bare minimum it needs to inform you that there is a different version on the server from when you were last online. Then give you the chance to merge things, etc.
Normal users aren't going to understand how to deal with that. Sure they can be made to understand, but they are going to be frustrated none the less.
What is the alternative, though? And how do you handle notifications and to whom?
I suppose everyone who is saving a new version that is different than the old one should be notified.
I can see it now, my boss and three other employees all take their laptops home over the weekend, and they all decide to work on the same file while offline. They come into the office Monday morning. The boss arrives first and the laptop syncs their file, then the three other people and again more syncing. Then some time later someone decides to look at the file (other than the last to arrive and presumably sync) and freaks out because their changes are gone.. not only that, but the file is different than what they were working on before.
Now can this happen with a file share, absolutely, but in my experience (which granted isn't a lot because this just doesn't happen much where I have worked/supported) it's much less likely an issue if someone is pulling a copy to their local laptop before go home and then copying it back when they return to the office.
But then again, perhaps this situation happens so infrequently that we shouldn't even worry about it.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
At bare minimum it needs to inform you that there is a different version on the server from when you were last online. Then give you the chance to merge things, etc.
Normal users aren't going to understand how to deal with that. Sure they can be made to understand, but they are going to be frustrated none the less.
What is the alternative, though? And how do you handle notifications and to whom?
I suppose everyone who is saving a new version that is different than the old one should be notified.
I can see it now, my boss and three other employees all take their laptops home over the weekend, and they all decide to work on the same file while offline. They come into the office Monday morning. The boss arrives first and the laptop syncs their file, then the three other people and again more syncing. Then some time later someone decides to look at the file (other than the last to arrive and presumably sync) and freaks out because their changes are gone.. not only that, but the file is different than what they were working on before.
Now can this happen with a file share, absolutely, but in my experience (which granted isn't a lot because this just doesn't happen much where I have worked/supported) it's much less likely an issue if someone is pulling a copy to their local laptop before go home and then copying it back when they return to the office.
But then again, perhaps this situation happens so infrequently that we shouldn't even worry about it.
How could that be the case? The situation that you describe is easily, and I mean this, thousands of times more likely to cause the problem. If you copy the file, hold it for a period of time, and then upload you are GOING TO overwrite. It won't warn you or anything. The other peoples' work is just gone. Poof.
With standard SharePoint you do Check Outs so that only one person can work on it at a time. That way you know when people are working on it, who has it and can ask them to release it for you to work on.
With ODfB the people who take it home would be getting each others' updates in real time so only if ODfB went offline or if they were somehow disconnected would they ever have issues at all and the overwrites are carefully handled.
I think you are in a situation of creating the problem by attempting to avoid it.
-
In your experience you have been seeing ODfB syncing causing problems but not pure overwrites? Sounds like almost certainly you have been losing data and people just don't notice.
-
@scottalanmiller said:
How could that be the case? The situation that you describe is easily, and I mean this, thousands of times more likely to cause the problem. If you copy the file, hold it for a period of time, and then upload you are GOING TO overwrite. It won't warn you or anything. The other peoples' work is just gone. Poof.
What? No they don't just overwrite without prompting you that a file with the same name is already there. Of course you're prompted, unless you somehow disabled that.
Is it perfect, of course not, but it sounds like SP will just save all the version (which is a good start, but also not perfect). -
@Dashrender said:
@scottalanmiller said:
How could that be the case? The situation that you describe is easily, and I mean this, thousands of times more likely to cause the problem. If you copy the file, hold it for a period of time, and then upload you are GOING TO overwrite. It won't warn you or anything. The other peoples' work is just gone. Poof.
What? No they don't just overwrite without prompting you that a file with the same name is already there. Of course you're prompted, unless you somehow disabled that.
Is it perfect, of course not, but it sounds like SP will just save all the version (which is a good start, but also not perfect).Doesn't that happen anyway, though, since the file already exists because that is where they copied it from in the first place. So it would always be the case that the file would already be there. Meaning that the warning is useless and people just lose data.
Other tools do live merging and all kinds of things. In the real world these problems almost never exist like they do with a traditional filesystem approach.
-
@scottalanmiller said:
With ODfB the people who take it home would be getting each others' updates in real time so only if ODfB went offline or if they were somehow disconnected would they ever have issues at all and the overwrites are carefully handled.
I think you are in a situation of creating the problem by attempting to avoid it.
You're assuming that the users get back online when they get home, which may or may not be the case.
But really I was trying to stay more within the spirit of the OP where he was looking for a solution where all of SP is offline, and users are working from their ODfB setup. Assuming multiple people all worked on the same file at the same time, this problem would happen.
Again, it's probably so rare that we have already spent more time discussing it than would take to solve the rare situation when it actually occurred.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
How could that be the case? The situation that you describe is easily, and I mean this, thousands of times more likely to cause the problem. If you copy the file, hold it for a period of time, and then upload you are GOING TO overwrite. It won't warn you or anything. The other peoples' work is just gone. Poof.
What? No they don't just overwrite without prompting you that a file with the same name is already there. Of course you're prompted, unless you somehow disabled that.
Is it perfect, of course not, but it sounds like SP will just save all the version (which is a good start, but also not perfect).Doesn't that happen anyway, though, since the file already exists because that is where they copied it from in the first place. So it would always be the case that the file would already be there. Meaning that the warning is useless and people just lose data.
Other tools do live merging and all kinds of things. In the real world these problems almost never exist like they do with a traditional filesystem approach.
Why would it be useless? because the user would just ignore it when copying the file back?
-
@Dashrender said:
You're assuming that the users get back online when they get home, which may or may not be the case.
You actually have a user that has a laptop, takes it home and keeps it offline so that they can't get email, surf the web or anything? This sounds possible only as a theory and even then on the contrived side. Who would do that?
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
How could that be the case? The situation that you describe is easily, and I mean this, thousands of times more likely to cause the problem. If you copy the file, hold it for a period of time, and then upload you are GOING TO overwrite. It won't warn you or anything. The other peoples' work is just gone. Poof.
What? No they don't just overwrite without prompting you that a file with the same name is already there. Of course you're prompted, unless you somehow disabled that.
Is it perfect, of course not, but it sounds like SP will just save all the version (which is a good start, but also not perfect).Doesn't that happen anyway, though, since the file already exists because that is where they copied it from in the first place. So it would always be the case that the file would already be there. Meaning that the warning is useless and people just lose data.
Other tools do live merging and all kinds of things. In the real world these problems almost never exist like they do with a traditional filesystem approach.
Why would it be useless? because the user would just ignore it when copying the file back?
Right, because it's a warning that would always be there whether they were overwriting someone else's changes or not. How would they know?
-
@scottalanmiller said:
@Dashrender said:
You're assuming that the users get back online when they get home, which may or may not be the case.
You actually have a user that has a laptop, takes it home and keeps it offline so that they can't get email, surf the web or anything? This sounds possible only as a theory and even then on the contrived side. Who would do that?
LOL my boss would do this.
-
@Dashrender said:
But really I was trying to stay more within the spirit of the OP where he was looking for a solution where all of SP is offline, and users are working from their ODfB setup. Assuming multiple people all worked on the same file at the same time, this problem would happen.
In general that would be pretty rare. Between how seldom SP is offline and how rarely people are collaborating and that the two would have to coincide AND be on a file type that doesn't support that AND have them do colliding updates.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
You're assuming that the users get back online when they get home, which may or may not be the case.
You actually have a user that has a laptop, takes it home and keeps it offline so that they can't get email, surf the web or anything? This sounds possible only as a theory and even then on the contrived side. Who would do that?
LOL my boss would do this.
That seems a bit mental. A computer user today who wants to act like they are on a Commodore 64?
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
How could that be the case? The situation that you describe is easily, and I mean this, thousands of times more likely to cause the problem. If you copy the file, hold it for a period of time, and then upload you are GOING TO overwrite. It won't warn you or anything. The other peoples' work is just gone. Poof.
What? No they don't just overwrite without prompting you that a file with the same name is already there. Of course you're prompted, unless you somehow disabled that.
Is it perfect, of course not, but it sounds like SP will just save all the version (which is a good start, but also not perfect).Doesn't that happen anyway, though, since the file already exists because that is where they copied it from in the first place. So it would always be the case that the file would already be there. Meaning that the warning is useless and people just lose data.
Other tools do live merging and all kinds of things. In the real world these problems almost never exist like they do with a traditional filesystem approach.
Why would it be useless? because the user would just ignore it when copying the file back?
Right, because it's a warning that would always be there whether they were overwriting someone else's changes or not. How would they know?
huh, If I saw that I wouldn't simply over right it.. I would check the file sizes and if different I would NOT overwrite, but maybe I'm unique.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
How could that be the case? The situation that you describe is easily, and I mean this, thousands of times more likely to cause the problem. If you copy the file, hold it for a period of time, and then upload you are GOING TO overwrite. It won't warn you or anything. The other peoples' work is just gone. Poof.
What? No they don't just overwrite without prompting you that a file with the same name is already there. Of course you're prompted, unless you somehow disabled that.
Is it perfect, of course not, but it sounds like SP will just save all the version (which is a good start, but also not perfect).Doesn't that happen anyway, though, since the file already exists because that is where they copied it from in the first place. So it would always be the case that the file would already be there. Meaning that the warning is useless and people just lose data.
Other tools do live merging and all kinds of things. In the real world these problems almost never exist like they do with a traditional filesystem approach.
Why would it be useless? because the user would just ignore it when copying the file back?
Right, because it's a warning that would always be there whether they were overwriting someone else's changes or not. How would they know?
huh, If I saw that I wouldn't simply over right it.. I would check the file sizes and if different I would NOT overwrite, but maybe I'm unique.
But you WOULD see it, because the file came from there. So this isn't a warning in any way. It's just what is expected if nothing had changed. So it isn't like the FS is warning you of anything. Why would you not just overwrite it?
-
Personally yes I would see it.. would normal users - that's hard to say.
Probably 50/50. -
I think the best option as of now is to let the users sync files that they want using ODFB and work on it. As mentioned probably not a good idea to sync all things locally and share, but it might be still possible to have one user account configured for the whole libraries and save it on a network drive, just in case if something goes wrong, at least we have the files, permissions can be done later on if we decide to get this up and running with any other system in case of an SP outage.
Seems like there are 3rd party tools which does this too.
-
@Dashrender said:
Personally yes I would see it.. would normal users - that's hard to say.
Probably 50/50.No, I mean by definitetion the process itself guarantees that the warning will come up 100% of the time so it is always pointless because it is a "crying wolf" warning.
