Создание снапшота - атомарная операция (lvm/btrfs/zfs), с точки зрения восстановления базы данных из этого снапшота, это будет то же самое, как если бы вы нажали reset на компьютере, даже лучше - сняли все процессы сервера баз данных с помощью жесткого kill -9 $pid (SIGKILL, его не отловить) ведь записи на диск не прервутся.
ВАЖНО, если база данных находится на одном томе! невозможно создать атомарно снапшот на нескольких томах. Вариант с запуском всей системы в виртуальной машине и созданием снапшотов ее средствами не рассматриваем, такой конфиг абсурден с точки зрения производительности.
Базы данных очень качественно следят за консистентностью записи, удаляют данные из лога только после того как завершат запись на диск, т.е. транзакция не завершится, пока данные не будут записаны окончательно. Это значит данные не будут повреждены.
С некоторой вероятностью, базу данных придется поднимать вручную, т.е. потребуется проверка целостности, например логи будут повреждены и их нужно будет удалять и т.п. Но обычно postgres справляется с аварийным выключением неплохо.
p.s. но я бы не рекомендовал такой способ все равно, особенно на постоянной основе.
Для создания резервной копии на живой базе я рекомендую использовать вторую машину, на которую настроена репликация базы. В этом случае эту вторую базу можно остановить, снять снапшот, возобновить работу (чтобы репликация догнала master - меньше нагрузка на диски, меньше оперативной памяти и допустим слабый процессор) а снапшот спокойно копировать, не опасаясь каких-либо проблем.
Данный способ нужно использовать на постоянной основе (мало того, требования к backup slave серверу значительно ниже чем рабочему master), и сам процесс создания копии никак не повлияет на работу исходной базы, когда как использование оригинальной базы, даже со снапшотом, значительно понизит ее производительность, так как копирование сильно нагружает дисковую подсистему.
Средний
