On 2/19/18 10:32 AM, Don Seiler wrote: > On Mon, Feb 19, 2018 at 9:21 AM, David Steele <david@xxxxxxxxxxxxx > <mailto:david@xxxxxxxxxxxxx>> wrote: > > > Yes, they are typically very small. The general exception to this rule > is if logs are stored in pg_log. I recommend storing logs out of the > PGDATA dir as they can be quite large and don't really make sense to > restore to another server. > > Files copied from the master will be marked as such in backup.manifest > (master:true) so you can check for yourself. > > > Good to know. And fortunately for this DB we do have pg_log (and > pg_xlog) symlinked to different volumes outside of $PGDATA. If pg_log is symlinked to PGDATA it will be copied. pg_xlog is not copied in any backup. > > > I did come up with a sort of Rube Goldberg-esque workaround for now > > involving using a clone of the prod standby VM from Veeam backup to use > > as the backup source (after stopping recovery and opening it as a > > standalone DB). > > You don't get PITR that way, of course, but at least it's a backup. As > long as your clone is consistent. > > > Yes it's a crash-consistent snapshot-based backup. I've done quite a few > restores from it and it works great. It can do PITR as well since I > would have all the WAL files from prod needed to keep recovering. But > for these cases I just recover it to the first consistent point and open > it for testing (or backups in this case). I don't think it would be safe to do PITR on a backup taken in this way. The WAL diverges even if you suppress a timeline switch. -- -David david@xxxxxxxxxxxxx
