Доброго времени суток.
У кого есть опыт работы с объемными архивами в rdiff-backup?
Мой вылез за пределы 27 млн. инод - это всего 51 инкремент
(ежедневный бэкап за последних 50 дней). Объем архива пока сказать
не могу, он еще вычисляется.
При попытке выполнить
rdiff-backup --remove-older-than 30D --force /backups/server
rdiff-backup съедает всю доступную память и сервер уходит в своп
(на сервере 2GB RAM). Пробовал смотреть на максимальной детализации
отладки - видно, что удаляются файлы, но память "капает" в неизвестном
направлении.
Пробовал смотреть исходники rdiff-backup в районе remove-older-than
# /usr/share/pyshared/rdiff_backup/manage.py
def delete_earlier_than_local(baserp, time):
"""Like delete_earlier_than, but run on local connection for speed"""
assert baserp.conn is Globals.local_connection
def yield_files(rp):
if rp.isdir():
for filename in rp.listdir():
for sub_rp in yield_files(rp.append(filename)):
yield sub_rp
yield rp
for rp in yield_files(baserp):
if ((rp.isincfile() and rp.getinctime() < time) or
(rp.isdir() and not rp.listdir())):
Log("Deleting increment file %s" % rp.path, 5)
rp.delete()
Насколько я знаю python, оно проходит по инкрементам и строит список
всех элементов в архиве, затем сравнивает метку времени и удаляет устаревшее.
Если предположить, что средняя длина пути 256 символов (грубо округляя
до 256 байт, то на полную итерацию этим алгоритмом потребуется
256 * 27000000 / 1024 / 1024 / 1024 ~= 6.43 GB
Встречал ли кто патчи, чтобы очищать ненужные элементы? Или инкременты
можно почистить другим способом?
--
WBR, Andrey Tataranovich
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
