GitLab doesn't include support for wiki pages (or I couldn't find it). Comparing apples to apples, I'm focusing on the issue tracker databases. I don't know where GitHub stores this kind of data.
If your team uses GitHub, you're paying a company to reliably store your data, and that's all the company does, and so I'm sure they have RAID0, plus backup drives, plus tape backups. If your team uses GitLab, you're hosting it yourself, so you are responsible for having reliable storage and backups. Obviously, it's infeasible for a tiny startup to have the same level of reliability that GitHub has.
palish's argument is that losing data is unlikely in either scenario. It's true that it's incredibly unlikely for both, but it's far more likely to happen if you roll your own solution. (It's incredibly unlikely that two values hash to one MD5. It's far less likely that two values hash to one SHA1. Either case is very unlikely, but SHA1 is magnitudes better.)
Oh, I thought that might have been your point. I think my point is that it's easy to trivially and even privately replicate git repos to backups.
If you trust only local + gitlab, I would agree, you at are a higher risk than local + github. The point is, gitlab can be every bit as open and accessible as github, as to make it easy to have another account mirror your git repos. GitHub + free BitBucket private repos = cheap + reliable + redundant repos.
I can now have a local gitlab resource that I keep synced with repos in github, almost trivially. bliss
For git data. You also want to backup your mysql database, otherwise all your issue tracker data is stored only in one place. (This is my point, I am apparently unable to properly express it.)
It's not that hard. Just make a script to do regular backups to S3. Cheap and easy. Hell, just run the whole thing on Amazon. Unlimited private repos, reliable uptime & backup, and cheap storage.
If your team uses GitHub, you're paying a company to reliably store your data, and that's all the company does, and so I'm sure they have RAID0, plus backup drives, plus tape backups. If your team uses GitLab, you're hosting it yourself, so you are responsible for having reliable storage and backups. Obviously, it's infeasible for a tiny startup to have the same level of reliability that GitHub has.
palish's argument is that losing data is unlikely in either scenario. It's true that it's incredibly unlikely for both, but it's far more likely to happen if you roll your own solution. (It's incredibly unlikely that two values hash to one MD5. It's far less likely that two values hash to one SHA1. Either case is very unlikely, but SHA1 is magnitudes better.)