Вопросы Теги

прокрутка diffs для устройства хранения данных очень подобных файлов?

Интересный вопрос, действительно. На первый взгляд я вижу следующие преимущества:

В первую очередь, Вы заявляете ту интерпретацию"."поскольку текущий каталог может быть сделан Shell или системными вызовами. Но наличие точечной записи в каталоге на самом деле удаляет эту необходимость и вызывает непротиворечивость даже на более низком уровне.

Но я не думаю, что это было основной идеей позади этого проектного решения.

Когда файл создается или удаляется из каталога, штамп времени изменения каталога должен быть обновлен, также. Эта метка времени хранится в ее inode. inode число хранится в соответствующей записи каталога.

ЕСЛИ БЫ точечная запись не была бы там, стандартные программы должны были бы искать inode число при записи для этого каталога в родительском каталоге, который вызовет поиск каталога снова.

НО к счастью в текущем каталоге существует точечная запись. Стандартная программа, которая добавляет или удаляет файл в текущем каталоге просто, должна перейти назад к первой записи (где точечная запись обычно находится), и сразу нашел inode число для текущего каталога.

Существует третья хорошая вещь о точечной записи:

Когда fsck проверяет гнилую файловую систему и должен иметь дело с несвязанными блоками, которые находятся также не в бесплатном списке, для него легко проверить, имеет ли блок данных (при интерпретации как список каталога) точечную запись, это указывает на inode, который в свою очередь указывает назад на этот блок данных. Если так, этот блок данных можно рассмотреть как потерянный каталог, который должен быть повторно подключен.

13
20.08.2010, 22:23
4 ответа

Два резервных инструмента, которые могут сохранить двоичный файл diffs, являются rdiff-резервным-копированием и двуличностью. Оба на основе librsync, но выше этого они ведут себя вполне по-другому. Rdiff-резервные-памяти последняя копия и реверс diffs, в то время как двуличность хранит традиционный возрастающий diffs. Эти два инструмента также предлагают другой набор периферийных функций.

11
27.01.2020, 19:53
  • 1
    IIUC, rdiff-резервное-копирование более привлекательно, поскольку это позволяет просматривать резервное копирование обычно, в то время как двуличность только имеет старую копию. –  tshepang 17.05.2011, 16:41

В последнее время я испытывал дампы базы данных хранения в мерзавце. Это может стать непрактичным, если Ваши дампы базы данных являются действительно большими, но это работало на меня для небольших баз данных (сайты Wordpress и т.п.).

Мой резервный сценарий примерно:

cd /where/I/keep/backups && \
mysqldump > backup.sql && \
git commit -q -m "db dump `date '+%F-%T'`" backup.sql
11
27.01.2020, 19:53
  • 1
    Это только хранит diffs? –  user394 20.08.2010, 15:40
  • 2
    Да. Это очень удобно! Можно "проверить" файл от любого момента времени, и мерзавец автоматически объединит diffs, чтобы дать Вам целый файл, поскольку он существовал в то время. –  sep332 20.08.2010, 16:39
  • 3
    Это сообщение в блоге (не мой) вдается в большее количество подробностей: viget.com/extend/backup-your-database-in-git комментарии добирается больше в профессионалов и недостатки и протесты. Я также добавлю, что при использовании мерзавца Вы получаете больше, чем просто способность откатывать версии. Можно также отметить дампы или иметь отдельные ответвления (dev/prod). Путем я смотрю на него, мерзавец (или вставьте свою любимую современную систему управления версиями), делает лучшее задание, чем я мог путем прокрутки моего собственного diff/gzip 'решения'. Одно предупреждение об этой статье: не продвигайте свои дампы к GitHub, если Вы не хотите их общедоступный (или платят за частный repo). –  drench 20.08.2010, 20:10
  • 4
    не только хранит diffs. На самом деле прежде всего, это хранит полный снимок каждого пересмотра, но с различной оптимизацией. См. этот превосходный ответ и его вопрос –  tremby 31.03.2014, 10:16

Вы могли сделать что-то вроде этого (с a.sql как Ваше еженедельное резервное копирование).

mysqldump > b.sql
diff a.sql b.sql > a1.diff
scp a1.diff backupserver:~/backup/

Ваши различные файлы станут больше к концу недели.

Мое предложение, хотя просто gzip это (использование gzip -9 для максимального сжатия). Мы делаем это в данный момент, и это дает использованию gz-файл 59 МБ, в то время как оригинал составляет 639 МБ.

1
27.01.2020, 19:53

(Я не сделал этого в производстве.)

Сделайте полное резервное копирование однажды в день или неделю. Резервное реле регистрируется однажды в час или день.

-2
27.01.2020, 19:53

Теги

Похожие вопросы