What is the --pgdata=- in your original command? Are you perhaps in the > wrong directory and not getting all the required files?
I run the pg_basebackup from the Slave on /var/lib/pgsql/9.2/data. So I'm not in the wrong directory... I'm out of fresh ideas. The rsync command is what I would go with, given > that I can't think of any other commands to try. I chose the pg_basebackup command just to not stop any database. It's out of circumstances to stop even the slave one... sorry... I really don't know what else to do. Have tried everything! Lucas On 10 January 2016 at 13:31, bricklen <brick...@gmail.com> wrote: > Bottom-posting is the convention in the postgresql lists, and makes it > easier to follow a long thread. > > On Sat, Jan 9, 2016 at 3:16 PM, drum.lu...@gmail.com <drum.lu...@gmail.com > > wrote: > >> My servers are not in the same network. A new pg_backup would take 30 >> hours to complete as I use --rate-limit 100MB. > > > If you had enough bandwidth, you could do some shell magic to parallelize > the rsync commands, or use something like > http://moo.nac.uci.edu/~hjm/parsync/ to do that. If you are limited by > bandwidth, then a single rsync run is probably what you're stuck with. > > >> I really need to put his server up! =\ >> > > If you were running zfs you could also take a snapshot of the fs and use > that for your base backup, but I assume you would have mentioned that if it > was an option. > > > >> I don't think that running a pg_basebackup one more time will solve the >> problem, because I've already done that! >> I could run actually, but the problem is that it takes 30h! hahahahah >> > > What is the --pgdata=- in your original command? Are you perhaps in the > wrong directory and not getting all the required files? > > > I'm out of fresh ideas. The rsync command is what I would go with, given > that I can't think of any other commands to try. > > > >> >> *Have a look:* >> http://www.postgresql.org/docs/9.2/static/app-pgbasebackup.html >> >> Note that there are some limitations in an online backup from the standby: >>> >> >> >> The backup history file is not created in the database cluster backed up. >>> There is no guarantee that all WAL files required for the backup are >>> archived at the end of backup. If you are planning to use the backup for an >>> archive recovery and want to ensure that all required files are available >>> at that moment, you need to include them into the backup by using -x >>> option. >>> >> > You had that in your original command I believe. >
