Wpisy Mogę bezpiecznie wykluczyć tworzenie kopii zapasowych

Planuję strategię tworzenia kopii zapasowych opartą na rsnapshot .

Chcę wykonać pełną kopię zapasową systemu, wyłączając pliki i katalogi, które byłyby bezużyteczne, aby przywracanie miało znów działający system. Już wykluczyłem:

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

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

Zastanawiam się, które inne wpisy mogę dodać do listy wykluczeń bez narażania przywróconego systemu. Mówiąc o „ogólnym” systemie Linux, czy możesz zasugerować dalsze globalne rozszerzenia, tymczasowe katalogi, pamięci podręczne itp. Mogę bezpiecznie wykluczyć?

Po pierwsze, powinieneś przeczytać trochę o składni włączania / wyłączania rsync. Mam wrażenie, że to, co chcesz zrobić, lepiej zrobić przy użyciu **globów niż *globusów. ( **Rozwija się do dowolnej liczby wpisów, natomiast *rozszerza się tylko do jednego wejścia ewentualnie dopasowanie wielu katalogów wpisy. Szczegóły są w man rsyncramach włączeń / wykluczeń reguł wzorców ).

To powiedziawszy, jeśli chcesz móc przywrócić system do znanego stanu roboczego z kopii zapasowej przy minimalnym wysiłku, powinieneś zachować ostrożność, wykluczając pliki lub katalogi. Sam używam rsnapshot i faktycznie przyjąłem odwrotne podejście: uwzględnij wszystko oprócz kilku starannie wybranych katalogów.

Więc mój plik rsnapshot.conf faktycznie stwierdza (z tabulatorami, aby parser plików konfiguracyjnych rsnapshot był szczęśliwy):

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

i bardzo niewiele więcej. Tak, oznacza to, że mogę skopiować nieco więcej niż to, co jest ściśle potrzebne, ale gwarantuje, że skopiowane zostanie wszystko, co nie jest zamierzone jako ephermal. Z powodu rsnapshot wykorzystującego zachowanie rsync w dowiązaniu do deduplikacji, jedyny realny koszt tego jest podczas pierwszego uruchomienia; po tym, zakładając, że masz miejsce docelowe kopii zapasowej w rozsądnej wielkości (w porównaniu z całkowitym rozmiarem zestawu danych), zajmuje to niewiele czasu lub miejsca na dysku. Wykluczam zawartość / backup, ponieważ tam montuję docelowy system plików kopii zapasowej; nie wykluczając, prowadziłoby to do kopiowania kopii zapasowej do siebie. Jednak dla uproszczenia, jeśli kiedykolwiek będę musiał przywrócić do stanu surowego, chcę zachować punkt montowania!

W moim przypadku również nie mogę rozsądnie wykorzystać one_fs 1; Używam ZFS z obecnie ~ 40 systemami plików. Wymienienie wszystkich z nich stanowiłoby koszmar konserwacji i spowodowałoby, że praca z systemami plików ZFS byłaby o wiele bardziej zaangażowana niż powinna.

Prawie wszystko, co chcesz wykluczyć powyżej i powyżej, będzie zależało od dystrybucji, więc udzielenie ogólnej odpowiedzi jest praktycznie niemożliwe. To powiedziawszy, prawdopodobnie znajdziesz kandydatów w / var.

Większość tego, co próbujesz zrobić, można prawdopodobnie osiągnąć po prostu za pomocą tego one_fsustawienia. Ustaw systemów plików, które chcesz umieścić w kopii zapasowych, a następnie użyć tego ustawienia, aby zignorować resztę ( proc, sys, dev, itd.). Uwzględnię, /lost+foundponieważ ten katalog powinien być zawsze pusty, chyba że utworzono kopię zapasową uszkodzonego systemu plików, w którym to przypadku prawdopodobnie potrzebujesz kopii zapasowej wszystkiego, co zostało fsckodzyskane. Również, .pyci .pyonie powinien być naprawdę w katalogu głównym na pierwszym miejscu, więc ja też usunąć te linie. /tmpi /var/tmpdotyczą jedynych pozostałych ścieżek w „ogólnym” systemie, które zawierają dane, które można niezawodnie wykluczyć z kopii zapasowych. Więc może spróbuj czegoś takiego:

one_fs 1

exclude /tmp/
exclude /var/tmp/

Uważam, że lepiej jest mieć listę pakietów, zawartość / etc, / home i dowolne dane użytkownika / systemu z / var i gdzie indziej. Zwykle szybsza jest ponowna instalacja pakietów i skopiowanie działającej konfiguracji.