Записи, які я можу сміливо виключати, роблячи резервні копії

Я планую стратегію резервного копіювання, засновану на rsnapshot .

Я хочу зробити повне резервне копіювання системи, виключаючи файли та каталоги, які були б марними для відновлення, щоб знову була робоча система. Я вже виключив:

# System:
exclude /dev/*
exclude /proc/*
exclude /sys/*
exclude /tmp/*
exclude /run/*
exclude /mnt/*
exclude /media/*
exclude /lost+found

# Application:
exclude /*.pyc
exclude /*.pyo

Цікаво, які ще записи я можу додати до списку виключень без шкоди для відновленої системи. Якщо говорити про "загальну" систему Linux, чи можете ви запропонувати подальші розширення глобальних програм, тимчасові каталоги, кеші тощо? Я можу безпечно виключити?

По-перше, вам слід трохи прочитати синтаксис включення / виключення rsync. У мене виникає відчуття, що те, що ти хочеш зробити, краще зробити за допомогою **глобусів, ніж *глобусів. ( **розширюється на будь-яку кількість записів, тоді як *розширюється лише на один запис, можливо, збігається з декількома записами каталогу . Деталі містяться в man rsyncрозділі Включити / виключити правила шаблону .)

Однак, якщо ви хочете мати можливість відновити систему до відомого робочого стану із резервної копії з мінімальними клопотами, вам слід бути обережними, виключаючи файли чи каталоги. Я використовую rsnapshot сам і насправді застосував протилежний підхід: включити все, крім кількох ретельно підібраних каталогів.

Тож мій rsnapshot.conf насправді констатує (з вкладками, щоб зробити аналізатор файлу конфігурації rsnapshot щасливим):

interval backup NNN # pick your poison
one_fs 0
exclude /backup/**
exclude /dev/**
exclude /proc/**
exclude /run/**
exclude /sys/**
exclude /tmp/**
backup / ./

і дуже мало іншого. Так, це означає, що я можу скопіювати трохи більше того, що є суворо необхідним, але це гарантує, що все, що не призначено як ephermal, буде скопійовано. Через rsnapshot, що використовує жорстку поведінку rsync-дедуплікації, реальна вартість для цього - під час першого запуску; після цього, якщо припустити, що у вас цільове місце резервного копіювання досить розмірного (порівняно з вашим загальним розміром набору даних), це займе зовсім небагато додаткового часу або місця на диску. Я виключаю вміст / резервного копіювання, оскільки там я монтую цільову файлову систему резервного копіювання; не виключаючи це призведе до ситуації копіювання резервної копії в себе. Однак для простоти, якщо мені коли-небудь потрібно буде відновити голий метал, я хочу зберегти точку кріплення!

У моєму випадку я також не можу розумно використовувати one_fs 1; Я запускаю ZFS з поточною ~ 40 файловою системою. Перерахування всіх цих питань явно було б кошмаром з технічного обслуговування і зробило б роботу із файловими системами ZFS набагато більше, ніж потрібно.

Практично все, що ви хочете виключити вище та поза цим, залежатиме від розподілу, так чи інакше, не можна дати загальної відповіді. Це означає, що ви, швидше за все, знайдете кандидатів під / var.

Більшість того, що ви намагаєтеся зробити, можливо, можливо, виконати просто за допомогою one_fsналаштування. Набір файлових систем , які ви хочете включити в резервних копіях, а потім використовувати цей параметр , щоб ігнорувати все інше ( proc, sys, devі т.д.). Я б включив, /lost+foundтому що цей каталог завжди повинен бути порожнім, якщо ви не створили резервну копію пошкодженої файлової системи, і в цьому випадку ви, мабуть, хочете створити резервну копію всього fsckвідновленого файлу. Крім того, .pycі .pyoнасправді не повинно бути в кореневому каталозі в першу чергу, тому я також видаляю ці рядки. /tmpі /var/tmpпро єдині залишилися шляхи в "загальній" системі, які містять дані, які можна надійно виключити з резервного копіювання. Тож, можливо, спробуйте щось на кшталт:

one_fs 1

exclude /tmp/
exclude /var/tmp/

Я вважаю, що краще мати список пакетів, вміст / etc, / home, а також будь-які дані користувача / системи з / var та інших. Зазвичай швидше перевстановити пакети та скопіювати назад робочий конфігурацію.