Solved Backup of Office 365 Sharepoint sites
-
@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.
-
@Ambarishrh said:
We are in the process of migrating our file server to SharePoint Online. Just wondering if any of you guys have a backup plan for SP online, to access files in case of any downtime with SP online. If so how can i do this?
Lots of posts here, so I'll just respond directly to this. Essentially, you've got two things to worry about here - DATA LOSS and CONNECTIVITY LOSS. A few thoughts on this -
-
Microsoft does all the backing up you could need and want, on a few levels. Number one, they have datacenter backups that we don't have access to. These are for when the shit really hits the fan. SharePoint, by nature, has many different ways of getting back a file. One, obviously, being version history. Second, you've got two levels of recycle bin on SharePoint. You've got the Site recycle bin and then you've got the Site Collection recycle bin, both of which have set retention (default is 30 days I believe). If that isn't good enough, you've also got the OneDrive for Business sync client that sync BOTH OD4B libraries, as well as ANY OTHER SharePoint library (yes, on-prem too - it's slick when it works). It has to be done on a library by library basis, so this certainly should NOT be considered part of any (sane) backup strategy, not to mention it's prone to sync errors.
-
With the above being said, I can understand your trepidation about not having access to files that were once happily stored on your file server (this was a gutsy move by the way - especially if it wasn't only for "User" files as opposed to real-deal NTFS shares on a Windows box somewhere on your network. SharePoint is a giant pain in the ass when it comes to file\path length and character-type limitations). We started "suggesting" to users that they take advantage of their OD4B accounts as a replacement for their "My Documents" storage. We have not started enforcing this yet because OneDrive has way too many sync issues that are going to be addressed, but haven't been yet. In fact, I was just dealing with a sync debacle as recently as yesterday. I digress. Anyway, backing up SharePoint in the cloud is a challenge and it can be costly to solve it. Essentially, there is no right answer here (as proven by the 60 plus replies here lol)
-
You mentioned your concern was downtime, so I'll address that. So it can basically come in two forms, right? One - your work ISP goes down and no one has internet access. Two - SharePoint Online goes down and the whole world can't get to it. While number 2 can certainly happen, think realistically at how possible that really is. Sure it can happen, but it's a long shot, at BEST. Looking at your ISP, I'm sure you have a nice little redundant firewall setup going so if ISP 1 goes down, ISP 2 takes over happily, right?
So to sum up, I think if you've got your head in the game with knowledge about how version history and how the recycle bin structure of SharePoint works, you really should be covered from DATA LOSS. If you've got redundant ISP's, you should be covered from CONNECTIVITY LOSS. So unless you've got some sort of regulatory requirement to back that sh*t up, I think you should be OK.
-
-
@AVI-NetworkGuy said:
So to sum up, I think if you've got your head in the game with knowledge about how version history and how the recycle bin structure of SharePoint works, you really should be covered from DATA LOSS. If you've got redundant ISP's, you should be covered from CONNECTIVITY LOSS. So unless you've got some sort of regulatory requirement to back that sh*t up, I think you should be OK.
Perfect! Yeah, i don't worry about an ISP outage, that got covered already, and i hope things go well with this move and seems like from all these replies, we can manage with the currently available options including versioning and backups from MS, which i believe can be restored in case of major issue by raising a support ticket!
Thanks a lot guys. Will let you know once i have this all moved to SP online, share the results
