Есть ли у кого-нибудь хорошее решение для резервного копирования / var в живой системе?
Все рекомендации, которые я видел до сих пор, не учитывают тот факт, что / var содержит жить data, и что восстановление файла, в который одновременно производилась запись во время захвата, потенциально опасно. Меня бы не поймали на мертвом резервном копировании / var / lib / pgsql с помощью прямой копии.
Обычно я не back up / var - такие вещи, как Postgres, должны быть зарезервированы в соответствии с процедурами резервного копирования в соответствующих руководствах и восстановлены аналогичным образом (например, только идиот может восстановить работающий экземпляр).
Если вам нужно создать резервную копию определенного подмножества / var (например, каталога данных postgres, каталога BDB openldap и т. Д.), Вы должны следовать соответствующим процедурам, указанным поставщиком программного обеспечения, или проявлять здравый смысл (убедитесь, что файлы неподвижны и т. Д.) )
Я делаю резервную копию / var с помощью rsync так, как я делаю все остальное, но затем я запускаю вторичный набор резервных копий только для баз данных, используя инструменты базы данных для создания дампа данных (или горячего копирования в некоторых случаях). Удивительно, но резервное копирование файловой системы оказалось более полезным, чем резервное копирование данных базы данных.
Кроме того, диски с моими базами данных находятся на всех запущенных файловых системах (или на оборудовании), что позволяет мгновенно делать снимки всей файловой системы. Периодическое выполнение этой процедуры - еще один отличный способ сохранить ваши данные в целости и сохранности.
Но если по какой-то причине вы все же хотите сделать последовательную резервную копию всего / var, вы можете смонтировать его как раздел lvm и сделать снимок lvm: http://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html
Вы упомянули резервное копирование postgres - для обеспечения согласованного резервного копирования postgres вы можете использовать pg_dump или комбинацию двоичных журналов вместе со снимком каталога данных postgres (так называемый PITR) http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#BACKUP-BASE-BACKUP
Не существует серебряной пули, которая бы сделала резервную копию всего за один раз и обеспечила логическую согласованность всех данных служб.