Re: [Marketing Mail] Re: LVM and Backups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Il 19/09/2018 09:28, Lange, Markus ha scritto:
On Wed, 2018-09-19 at 08:55 +0200, Alessandro Baggi wrote:
Il 18/09/2018 17:14, Gordon Messmer ha scritto:
On 9/17/18 11:38 PM, Alessandro Baggi wrote:
Il 17/09/2018 22:12, Gordon Messmer ha scritto:
That doesn't look right.  It should look more like 1) stop or
freeze
all of the services (httpd and database), 2) make the snapshot,
3)
start or thaw all of the services, 4) mount the snapshot, 5)
back up
the data, 6) remove the snapshot.

About database setup I perform backups via pg_dump so how the
snapshot
affects pgsql database? What your suggestion I must perform
database
backup copying only filesystem file and not pgsql.sql database
dump?


If you want a plain-text dump of the DB, you can do that before the
LVM
snapshot sequence: 1) pg_dump, 2) stop or freeze all of the
services
(httpd and database), 3) make the snapshot, 4) start or thaw all of
the
services, 5) mount the snapshot, 6) back up the data, 7) remove
the
snapshot.

Typically, the reason you want to use snapshots for the backup is
that
you don't need to do pg_dump to get a consistent DB backup,
though.
pg_dump style backups are extremely slow to restore.  If you freeze
the
DB, make a snapshot, and thaw, you can make a safe, consistent
backup of
the DB files directly, and restore in minimal time.


Are you using bacula's built-in snapshot support, or are you
rolling
your own?

No I'm using pre/post job script where I have lvm commands to
create
and destroy snapshot volume.


I really recommend using a ready-made process rather than rolling
your
own.  Bacula has snapshot support.  Alternately, my project can
manage
snapshots and handle freezing / thawing PostgreSQL services.  I
think
it's a better option than Bacula's, but either is better than
reinventing this wheel.

https://bitbucket.org/gordonmessmer/dragonsdawn-snapshot

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos

Thank you for the suggestion.

I don't know why I considered pg_dump better then filesystem backup.
At
this moment I prefer pg_dump because in this mode I can restore data
on
different version of postgresql. With filesystem dump I can restore
only
for a specific version. Is right?

I will give a try.

Thank you again for suggestions.

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos

Hi,

an restore may need additional attention while restoring database files
to a different version of postgres. However, while the versions does
not differ that much (an official upgrade path exists, or no layout
change was made between the versions) the files work just as if you
updated the database using yum (check out spec file from source pkg to
find out what happens on package upgrades, you may need to do upgrade
steps manually).

This should only be a problem when you try to restore to a new major
version of postgres. But in that case I would recommend an additional
pg_dump backup to have a save fallback.

best regards

ps: I do not use postgres, please understand my testimony as not tested
practically.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos


Thank you for the suggestion.

Best regards

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]


  Powered by Linux