Чи безпечно використовувати жорсткий диск під час роботи rsync?

Я планую створити резервну копію великих великих жорстких дисків rsyncі передбачаю, що це займе кілька днів. Чи безпечно використовувати оригінальний жорсткий диск (додавання файлів) під час rsyncроботи? Або краще залишити жорсткі диски недоторканими до rsyncзавершення?

Як вже вказували інші, безпечно читати з вихідного диска або використовувати цільовий диск поза цільовим каталогом, поки rsync працює. Це також безпечно читати в цільовому каталозі, особливо якщо цільовий каталог заповнюється виключно запуском rsync.

Що, як правило, не безпечно - це писати всередині вихідного каталогу під час роботи rsync. "Записує" - це все, що змінює вміст вихідного каталогу або будь-якого його підкаталогу, тому включає оновлення файлів, видалення, створення тощо.

Це фактично нічого не порушить , але rsync зміна може насправді отримати або скористатись для копіювання в цільове місце. Це залежить від типу змін, чи сканував rsync цей конкретний каталог і чи rsync скопіював відповідний файл чи каталог.

Однак існує простий спосіб цього: як тільки він закінчиться, запустіть rsync знову, з тими ж параметрами. (Якщо у вас є якийсь фанк-фактор видалення; якщо це зробити, то будьте трохи обережнішими.) Це призведе до повторного сканування джерела та перенесення будь-яких відмінностей, які не були зібрані під час початкового запуску.

Другий запуск повинен перенести лише відмінності, що відбулися під час попереднього запуску rsync, і як такий завершиться набагато швидше. Таким чином, ви можете сміливо користуватися комп’ютером нормально під час першого запуску, але слід максимально уникати будь-яких змін джерела під час другого запуску. Якщо ви можете, настійно подумайте про повторне перезавантаження вихідної файлової системи лише для читання перед початком другого запуску rsync. (Щось подібне mount -o ro,remount /media/sourceповинно робити.)

Це залежить від системи резервного копіювання, яку ви використовуєте, але в цілому погана ідея змінювати вміст пристрою під час резервного копіювання. Однак ви можете прочитати його зміст; це безпечна робота, навіть якщо це сповільнить процес.

У вашому випадку rsyncбуде складено список файлів, а потім запустіть резервну копію. Тому будь-який файл, який ви додасте до вихідного жорсткого диска після запуску резервної копії, не буде скопійовано.

Що я роблю, це взагалі не використовувати пристрій під час створення резервної копії. Це більш безпечний спосіб отримати швидку та послідовну резервну копію.

Безпечно читати дані з вихідних областей під час rsyncроботи, але якщо ви оновлюєте що-небудь, копія, яка rsyncстворює / оновлює, ймовірно, буде непослідовною:

1. Якщо ви оновите файл, який rsync вже відсканував, оновлення не відображатиметься до наступного запуску. Якщо ви оновите файл, який ще не потрібно сканувати, зміни будуть дотримуватися в пункті призначення. Якщо ви оновите файли, які були і не скановані, ви отримаєте суміш старої та нової версій у призначенні.

2. Якщо ви додасте файл до вже відсканованого каталогу, він буде пропущений із цільової копії цього разу. Якщо ви вилучите файл із вже відсканованого каталогу, цього разу його буде залишено в цільовій копії. Залежно від способу виклику rsyncвсе дерево може бути скановано на старті або воно може бути поступово відскановано, як відбувається процес синхронізації.

3. За деяких обставин rsyncпобачите неузгодженість і попередить вас. Якщо ви вилучите файл або підкаталог з каталогу, який вже був відсканований, але його вміст не було відскановано, ви отримаєте повідомлення про помилку про відсутність об'єкта. У подібних обставинах іноді (якщо розмір та / або мітка часу змінився) також можна попередити про файли, що змінюються в середині сканування.

Для деяких резервних копій ця невідповідність може не бути масовою проблемою, але для більшості це буде так, рекомендується не намагатися синхронізувати джерело, що активно змінюється.

Якщо ви використовуєте LVM для частини своєї системи зберігання даних, ви можете скористатися тимчасовим знімком, щоб зробити резервну копію в часі. Для цього потрібно, щоб у групі гучності було достатньо місця, щоб створити об'єм знімка, достатньо великий, щоб утримати всі зміни, які відбудуться протягом тривалості необхідного знімка. Перегляньте документацію LVM (або один із багатьох прикладів в Інтернеті: шукайте "резервну копію знімків LVM" або подібну інформацію) для отримання більш детальної інформації.

Навіть без LVM деякі файлові системи підтримують самі знімки - тому ви, можливо, також захочете вивчити цей варіант.

Якщо ви хочете створити резервну копію великих активних томів без тривалого простою і не можете використовувати знімки, можливо, достатньо запустити сканування "в реальному часі" до завершення, а потім зупинити доступ до тома і запустити інший процес rsync, який може зайняти набагато менше часу (якщо дуже мало змінилося, воно буде просто сканувати дерево каталогів, а потім кілька оновлених файлів). Таким чином, тривалість, протягом якої слід уникати змін, може бути значно коротшою.

• Джерело HDD може читати що завгодно під час rsync.

• Джерело HDD може записувати будь-який вміст, не пов'язаний із вмістом rsync.

• Призначення жорсткий диск може читати що завгодно під час rsync.

• Місцевий жорсткий диск може записувати що завгодно під час rsync з умовою мати достатньо місця для синхронізованого вмісту.

Звичайно, у будь-якому випадку відбудеться зниження продуктивності.

Усі нинішні відповіді говорять про безпеку даних з точки зору послідовності та припускаючи досконале обладнання.

Ще одна річ, яку слід врахувати, - це сама безпека обладнання. Якщо у вас немає резервних копій жорстких дисків, які можуть бути на межі виходу з ладу (ви, можливо, ще не знаєте), і ви робите початкову комплексну резервну копію, не використовуйте її. Навіть не монтуйте його, якщо дані критичні. Ви можете використовувати такий інструмент, як ddклонувати диск як блоковий пристрій. Що ви не хочете, щоб шукати дискову голівку та, можливо, писати під час спроби зробити резервну копію. Плюс ddповинен бути швидшим для початкової резервної копії, оскільки він просто копіює біти для того, щоб (якщо диск в основному не повний, я вважаю, що rsync виграє і в початковому випадку).

Для наступних додаткових резервних копій rsync є прекрасним вибором, і я погоджуюся з іншими відповідями на 100%.