- 06 Oct, 2015 3 commits
-
-
Jacob Vosmaer authored
-
Jacob Vosmaer authored
Documentation elsewhere refers to this internal path, let's keep it.
-
Jacob Vosmaer authored
By using light gzip compression we can save a lot of disk IO during the backup.
-
- 18 Sep, 2015 1 commit
-
-
Valery Sizov authored
-
- 21 Aug, 2015 1 commit
-
-
Jacob Vosmaer authored
The change in baa15792 broke backup restore fucnctionality. This would not lead to data loss, but it prevented the restore script from working. This bug exists only in 7.14.0 release candidate versions, not in 7.13. Reported in https://github.com/gitlabhq/gitlabhq/issues/9571 .
-
- 12 Aug, 2015 1 commit
-
-
Ted Strzalkowski authored
command line.
-
- 30 Jul, 2015 1 commit
-
-
Jacob Vosmaer authored
-
- 29 Jul, 2015 1 commit
-
-
Jacob Vosmaer authored
This sidesteps problems with running 'chmod' on some CIFS mounts.
-
- 21 Jul, 2015 1 commit
-
-
Jacob Vosmaer authored
The existing behavior of the backups is to overwrite whatever data was still there in the scratch directories. This broke when we added a 'gzip' step because 'gzip database.sql' will fail if 'database.sql.gz' already exists. Doing 'rm -f database.sql.gz' before the 'gzip' avoids this failure.
-
- 07 Jul, 2015 1 commit
-
-
Jacob Vosmaer authored
We were using hacks to drop tables etc during a Postgres backup restore. With this change, we let pg_dump insert the DROP TABLE statements it needs at the start of the SQL dump.
-
- 06 Jul, 2015 1 commit
-
-
Kamil Trzcinski authored
-
- 20 Nov, 2014 1 commit
-
-
Jacob Vosmaer authored
-
- 28 Oct, 2014 1 commit
-
-
Jacob Vosmaer authored
-
- 01 Oct, 2014 1 commit
-
-
Jacob Vosmaer authored
This change also shows the output of failed Git commands during the backup.
-
- 28 Mar, 2014 1 commit
-
-
Jacob Vosmaer authored
Invoking 'db:schema:load' turned out to be a bad idea: when downgrading an existing GitLab installation, the schema of the newer version would be preserved when trying to import the old version.
-
- 26 Feb, 2014 1 commit
-
-
Jacob Vosmaer authored
The expected behavior during a GitLab backup restore is to overwrite existing database data. This works for MySQL because the output of mysqldump contains 'DROP TABLE IF EXISTS' statements. pg_dump on the other hand assumes that one will restore into an empty database. When this is not the case, during the restore with psql some of the data will be skipped if existing data is 'in the way'. By first invoking `rake db:schema:load` during a Postgres GitLab backup restore, we make sure that all important data is correctly restored.
-
- 23 Jan, 2014 1 commit
-
-
Jacob Vosmaer authored
-
- 06 Nov, 2013 1 commit
-
-
Jacob Vosmaer authored
-
- 05 Nov, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
This reverts commit c46eaca9.
-
- 04 Nov, 2013 1 commit
-
-
Nigel Kukard authored
- Database name may contain characters which are not shell friendly - Database password could contain the same - While we at it there is no harm in escaping generated paths too - Refactored 2-line system(command) Signed-off-by: Nigel Kukard <nkukard@lbsd.net>
-
- 10 Jun, 2013 1 commit
-
-
andrewwutw authored
Use psql instead of pg_restore to restore SQL dump file.
-
- 07 May, 2013 1 commit
-
-
Axilleas Pipinellis authored
By default there is no public/uploads directory when no attachments are uploaded. Prompt users to create the uploads directory during install otherwise the backup task will fail. Place mysqldump args in single quotes to avoid error if password contains special characters. Signed-off-by: Axilleas Pipinellis <axilleas@archlinux.gr>
-
- 05 Apr, 2013 1 commit
-
-
Dmitriy Zaporozhets authored
-