Has anyone had any success with GeoGig? Billed as: "GeoGig is an open source tool that draws inspiration from Git, but adapts its core concepts to handle distributed versioning of geospatial data.": http://geogig.org/
I have not yet tried so this is a query, not a recommendation. Chris Berens, GISc www.mapland.co.za +27 (0)82 567 9322 On 18 July 2016 at 12:22, Jonathan Moules <[email protected]> wrote: > On top of the excellent suggestions that have come out of this thread, > it's worth stating that a backup is worthless if it is untested. > > You should regularly test backups to ensure you can restore from them; > this applies to all backups. There are plenty of horror stories out there > from organisations/people that kept "backups" they never tested, and when > they needed them they were corrupt or otherwise not what they should have > been. > So be sure test your backups! :-) > > Cheers, > Jonathan > > > ---- On Sat, 16 Jul 2016 07:54:56 +0100 *Bo Victor Thomsen > <[email protected] <[email protected]>>* wrote ---- > > I haven't any extensive experience with moving databases from windows to > linux or vice versa, but I've been moving (backup/restore) databases > between windows hundred of times. > > - I'm normally using the "Custom/binary" format, because it's the > fastest method to do the backup/restore cycle. > - When I'm creating/ structuring a new spatial database, I always > leave the "public" schema alone and put data in another schema created for > that purpose. > - When doing a backup for the purpose of moving a database, I only > backup the aforementioned *data* schema, *not* the "public" schema, thus > avoiding taking backup of hundreds of PostGIS functions residing in schema > "public". This makes it easier to move spatial data from one > PostGIS-enabled database to another without annoying errors. > - And - just as you - I use the "plain" format when it's necessary to > make some changes to the structure or fields with a text editor during the > move of the database. > > Regards > > Bo Victor Thomsen > AestasGIS > Denmark > > Den 15/07/16 kl. 15:23 skrev Micha Silver: > > Hi > > > ------ Original Message ------ Subject: Re: [Qgis-user] Backing up GIS > Data Date: Fri, 15 Jul 2016 07:04:20 +0200 To: Qgis-user From: Bo Victor > Thomsen > > As an old GIS database dog - > > - It's a wise and smart decision to use Postgres/PostGis for storing > and using spatial data. > - As for backup: Do *exactly* as Jeff writes :-). "Point in time" > backups are nice, but not the best backup solution for Postgres databases. > Jeff's solution is. > > > Regards > > Bo Victor Thomsen > AestasGIS > Denmark > > > > > > > Den 14/07/16 kl. 21:26 skrev Jeff McKenna: > > Hi Tyler, > > This is a good question, and an important one, and don't feel bad about > posting it here - likely we can all learn from this discussion, as it > definitely involves the whole QGIS community. > > I have quite a lot of experience backing up databases, especially > PostgreSQL/PostGIS databases. I can tell you that it is for sure important > to run "pg_dump" as a daily backup (in addition to your whole server > image/backup) - that pg_dump has saved me and my clients hundreds of times, > and it is very portable and easy to access (as opposed to your whole > image/machine backup). One very important point (that's I've learned from > experience) when using pg_dump is to *always* use the custom > binary/compressed output format (the "--format=c" commandline switch for > pg_dump). I've had > > > I have always used the default "plain" format for pg_dump backups. When > time comes to migrate data to a new installation, it allows me to edit the > SQL backup file: restore only some of the tables, change owners, schema > names, even change the database name. This is just a minor convenience. Am > I making a mistake? Should I move to the binary format to insure > reliability? > > Thanks > > terrible times with the other output format types, especially when > restoring a database from a Windows server to a Linux server etc (with > hardcoded paths inside the backup). I live by that format, swear by it, > from experience, moving so many client databases from one machine to > another. > > Another mailing list to keep in mind is the PostGIS mailing list, where > these backup topics also pop up from time to time - and discussions are > more geo-related, so are very helpful, than just the generic PostgreSQL > mailing list. > > So, definitely implement an additional backup process using pg_dump (you > can experiment restoring it through the "pg_restore" command), you won't > regret the effort spent. > > Happy QGIS-ing, > > -jeff > > > > > > _______________________________________________ Qgis-user mailing list > [email protected] List info: > http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: > http://lists.osgeo.org/mailman/listinfo/qgis-user > > Micha Silver > Arava Drainage Authority > +972-523-665918 > > > _______________________________________________ > Qgis-user mailing list > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user > > > > > _______________________________________________ > Qgis-user mailing list > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user >
_______________________________________________ Qgis-user mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
