Migawka `cp -al`, której twarde linki są przekierowywane do nowego pliku podczas edycji

Staram się regularnie robić migawki ogromnego folderu.

Przeczytałem tutaj: http://www.mikerubel.org/computers/rsync_snapshots/#Incremental,
który cp -alwykonuje migawkę folderu po prostu kopiując twarde linki.

To wszystko świetnie, ale problem polega na tym, że w tej migawce, jeśli zmienię plik, zmienia się we wszystkich migawkach. Zamiast tego chciałbym, aby system utworzył nowy plik podczas zmiany i zamiast tego utworzył łącze do niego. W ten sposób każda migawka nie stałaby się niepoprawna podczas edycji pierwszego pliku.

Jak mogę to osiągnąć?

ps Próbowałem rsync -a --delete --link-dest=../backup.1 source_directory/ backup.0/, ale ma ten sam problem.

Tak działają twarde linki. Ale są na to sposoby:

Przychodzi mi na myśl kilka opcji:

• Użyj systemu plików z obsługą plików kopiowania przy zapisie, takich jak btrfs. Oczywiście, jeśli używasz btrfs, po prostu użyjesz jego rodzimych migawek ... Jeśli twój system plików obsługuje to, możesz użyć cp --reflink=always. Niestety ext4 tego nie obsługuje.
• Udostępniaj tylko twarde linki w swoich migawkach, a nie w oryginale. To znaczy, kiedy po raz pierwszy zobaczysz daną wersję pliku, skopiuj ją do migawki. Ale następnym razem połącz go z tym z poprzedniej migawki. (Nie jestem pewien, jakiego programu użyłem do tego - dekadę temu - ale wyszukiwanie ujawnia dirvish, obnam, storebackup i rsnapshot)
• W zależności od tego, w jaki sposób zmieniane są twoje pliki, możesz być w stanie zagwarantować, że do ich zmiany zostanie użyta temperatura zapisu / zmiana nazwy, a następnie zerwanie twardego łącza - więc wersja w migawce pozostanie nieskazitelna. Jest to jednak mniej bezpieczne, ponieważ błędy mogą uszkodzić twoją migawkę.
• Wykonaj migawki LVM całego systemu plików.

Oczywiście istnieje druga opcja - użyj odpowiedniego systemu tworzenia kopii zapasowych. Większość z nich potrafi jedynie tworzyć kopie zapasowe zmienionych plików.

To, czego szukasz, to forma kopiowania przy zapisie , w której wiele plików o tej samej zawartości używa tego samego miejsca na dysku, dopóki jeden z nich nie zostanie zmodyfikowany. Twarde linki implementują kopiowanie przy zapisie tylko wtedy, gdy aplikacja, która dokonuje zapisu, usuwa plik i tworzy nowy plik o tej samej nazwie (co zwykle odbywa się poprzez utworzenie nowego pliku pod inną nazwą, a następnie przeniesienie go na miejsce). Aplikacja, której używasz, najwyraźniej tego nie robi: zastępuje istniejący plik.

Niektóre aplikacje można skonfigurować do korzystania ze strategii zastępowania. Niektóre aplikacje domyślnie używają strategii zastępowania, ale stosują strategię zastępowania, gdy widzą plik z wieloma dowiązaniami twardymi, właśnie po to, aby nie zerwać twardych dowiązań. Twoja obecna technika migawek będzie działać, jeśli możesz skonfigurować aplikację do zastępowania zamiast zastępowania.

Fl-cow modyfikuje programy, aby systematycznie używać strategii zastępowania plików z wieloma twardymi linkami.

Alternatywnie możesz przechowywać swoje pliki w systemie plików, który wykonuje kopiowanie przy zapisie lub deduplikację, lub masz funkcję migawki i nie martw się o twarde linki: Btrfs lub Zfs . W zależności od schematu partycjonowania opcją może być użycie migawek LVM.

Polecam użyć odpowiedniego narzędzia do tworzenia migawek. Tworzenie niezawodnych kopii zapasowych jest zaskakująco trudne. Prawdopodobnie chcesz rsnapshot .

Poniżej znajduje się napisany przeze mnie skrypt ruby, który otacza „cp -al” i rsync w ładny skrypt, który można uruchomić ręcznie lub za pomocą crona. Miejsce docelowe może być lokalne lub zdalne (przez ssh):

Ghetto Timemachine

Podstawowa odpowiedź na twoje pytanie, jak wspomniano w poprzednim komentarzu, źródło musi być oddzielone od twardych linków. Np. Załóż codzienną kopię zapasową katalogu domowego:

Źródło:

• / home / flakrat

Miejsce docelowe:

• / data / backup / daily
  • /poniedziałek
  • /wtorek
  • /środa
  • /czwartek
  • ...

Twarde linki są tworzone przez uruchomienie „cp -al” w stosunku do wczorajszej kopii zapasowej. Powiedz, że jest wtorek rano, kiedy go uruchomisz:

cd /data/backup/daily

rm -rf tuesday

cp -al monday tuesday

rsync -a --delete /home/flakrat /data/backup/daily/tuesday/

rdiff-backup wydaje się robić, co chcesz, sprawdź to.

Korzystając z rsync, musisz najpierw wykonać pełną kopię zapasową, nie używając twardych łączy. Następna kopia zapasowa może wskazywać na poprzednią kopię zapasową i twardy link do niej. W ten sposób kopie zapasowe nie są na stałe połączone z plikami roboczymi (tymi, które modyfikujesz). Przykład. Jeśli moja poprzednia kopia zapasowa była tak, folder backup.01, mój skrypt kopii zapasowej najpierw zwiększyłby foldery, zmieniając ich nazwę o jeden, aby backup.01 stał się backup.02. Następnie skrypt tworzy nowy pusty folder o nazwie backup.01. wtedy rscync nową kopię zapasową do nowego folderu i twardy link do kopii zapasowej.02, aby tylko nowe pliki zajmowały miejsce w kopii zapasowej. Komenda rsync wyglądałaby mniej więcej tak: rsync -rlt sourcepath backuppath / backup.01 --link-dest = backuppath / backup.02

Jak widać, całe twarde linkowanie odbywa się na ścieżce kopii zapasowej. W ten sposób nie musisz martwić się o kopiowanie podczas zapisu podczas modyfikowania plików w ścieżce źródłowej.