Restic: Распечатайте размер резервной копии при перечислении снимков (улучшение)

Спасибо за предложение. Какого размера вы ожидаете? Поскольку все данные дедуплицированы, «размер» конкретного снимка не так просто определить. Будет ли это размер всех данных, на которые есть ссылка в этом снимке? Или данные, которые еще не хранились в репо на момент создания снимка (новые данные)?

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

Сколько места было потрачено впустую этой ночью? Ой, это в 10 раз больше, чем прошлой ночью, я где-то оставил хлам (или забыл положить исключения), лучше убрать. ;)

+1 за предложение @zcalusic

Проблема с размером «новых» больших двоичных объектов (добавленных этим конкретным снимком) со временем становится менее актуальной, поскольку на эти капли будут ссылаться более поздние снимки. Кроме того, при удалении более ранних снимков количество больших двоичных объектов, на которые ссылается конкретный снимок, будет расти.

Я думаю, полезно распечатать эту информацию сразу после завершения резервного копирования, и мы также можем записать ее в структуру данных моментального снимка в репо. Я планировал добавить какое-то «подробное» представление для конкретного снимка, и я думаю, что было бы неплохо отобразить там количество и размер новых больших двоичных объектов, но в обзоре (команда snapshots ) это недостаточно актуально. Я думаю, что restic должен отображать весь размер конкретного снимка (то, что вы получите, если восстановите его), потому что это не меняется.

Мне сразу напомнили о флаге статистики rdiff-backup (см. https://www.systutorials.com/docs/linux/man/1-rdiff-backup-statistics/). иногда приятно видеть какую-то дельту между двумя снимками.

В самом деле, но это другое дело: он вычисляется в реальном времени и сравнивает два снимка. Мы можем добавить что-то подобное, но делать это для обзорного списка snapshots слишком дорого (по крайней мере, с той информацией, которая у нас есть в структурах данных прямо сейчас).

Было бы полезно знать размер данных, «уникальных» для снимка, по сравнению с общим размером (включая дедуплицированные данные) снимка.

IMO было бы весьма полезно иметь представление о том, сколько дополнительного места было использовано для нового снимка. Это может быть даже просто физическое пространство хранения, вычисленное во время резервного копирования и сохраненное в метаданных моментального снимка. Если какой-либо снимок будет удален, эти метаданные должны быть аннулированы во всех будущих снимках.

Думаю, я был бы признателен за такую ​​функцию, даже если бы больше ничего не было сделано в этом направлении. Однако вариант пересчета этого «дополнительного размера» после удаления некоторых предыдущих резервных копий также был бы неплохим. Я думаю, что это то, что BackupLoupe делает для Time Machine в Mac OS. (Дедупликация в Time Machine очень проста, но проблема определения «размера моментального снимка» остается прежней).

Самая фундаментальная вещь, которую я хотел бы знать сразу же, - это сколько дискового пространства будет занимать содержимое снимка X на целевом диске, если я его восстановлю.

Предпочтительно я мог бы получить эту информацию только для подмножества файлов, например, если бы была команда size которая принимала тот же тип параметров включения / исключения, что и команда restore . Или, если у команды restore есть опция, которая заставляет ее просто сообщать подобную статистику вместо фактического восстановления.

Спасибо @rawtaz за то, что указал мне на эту проблему.

Я храню резервные копии в измеряемом хранилище (Backblaze B2). Я хочу знать, сколько новых данных я создаю каждый раз, когда выполняю резервное копирование. Похоже, это должно быть легко вычислить в процессе резервного копирования; Я был бы счастлив, если бы restic просто зарегистрировал это как часть завершения резервного копирования ... но похоже, что также может быть полезно сохранить это как атрибут снимка (чтобы его можно было запрашивать в будущем).

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

Какие-нибудь Новости?

Привет

Я хотел бы поддержать это предложение. В дополнение к «Насколько велик был бы этот снимок, если бы я его восстановил» для любого существующего снимка и «сколько этот снимок добавил» при создании снимка, у меня есть третье предложение:

Также было бы полезно ответить на вопрос: «Насколько уменьшится размер моего репо, если я удалю следующие снимки?» Это было бы полезно в restic forget --prune --dry-run при принятии решения о сбросе снимков. Например, я недавно сбросил 20 из 40 снимков в репо, и он уменьшил размер с 1,1 ГБ до 1,0 ГБ. Если бы я знал, что это сэкономило бы только 100 МБ, я бы, вероятно, сохранил старые снимки.

@mholt сделал # 1729, чтобы показать некоторую статистику. Может быть, он сможет вмешаться, чтобы сказать что-нибудь о продвижении этого пиара.

@dimejo Готово - просто жду, когда его рассмотрят / объединят. :)

Прыгая на действительно старую проблему, но для меня есть два важных поля размера, когда я думаю о снимках.

• Размер снимка в хранилище
• Размер восстановления

например

$ restic snapshots
ID        Date                 Host        Tags        Directory    Snapshot Size   Restore Size 
--------------------------------------------------------------------------------------------------
5b969a0e  2016-12-09 15:10:32  localhost               myfile       10 MB           57 GB

По крайней мере, тогда я мог бы сказать, сколько места занимает один моментальный снимок и сколько места мне нужно для восстановления.

Как уже указывал @ fd0 , печать размера при каждом вызове restic snapshots была бы довольно дорогой командой. Но вы можете использовать restic stats, чтобы распечатать размер отдельных снимков или всего репозитория.

Я думаю, полезно распечатать эту информацию сразу после завершения резервного копирования, и мы также можем записать ее в структуру данных моментального снимка в репо. Я планировал добавить какое-то «подробное» представление для конкретного снимка, и я думаю, что было бы неплохо отобразить там количество и размер новых больших двоичных объектов, но в обзоре (команда snapshots ) это недостаточно актуально. Я думаю, что restic должен отображать весь размер конкретного снимка (то, что вы получите, если восстановите его), потому что это не меняется.

Отличная идея! Это улучшение стоит в очереди? Общий размер дедуплицированных данных в репозитории также будет полезен в таком синопсисе.

Есть ли обновления для этой функции? Это очень полезно , чтобы иметь возможность видеть каждый размер снимка и его восстановление размера.

+1

Не сейчас. Если есть обновления, они будут отображаться в этом выпуске.