рішення для резервного копіювання з підтримкою btrfs

14

Цього місяця btrfs потрапляє на виробництво в Oracle EL 14 (разом з роботою fsck та очищенням від Linux 3.2), я думав переробити своє поточне рішення для резервного копіювання, щоб використовувати його. Зауважте, що я думаю про те, щоб зробити це для невеликих обсягів даних, менше 10 ТБ, що є досить статичним (менше 1% змінюється щодня). Коротше кажучи, резервне рішення для резервного копіювання SMB / SOHO.

Що робити резервну копію:

зробіть LVM-знімок ext [234] / XFS / JFS на виробничому сервері
rsync/ передача змінених даних у btrfs на резервному сервері
знімок файлової системи btrfs
відкиньте старі знімки, коли вільного місця не вистачає

Плюси:

Усі файли легко доступні, не потрібна декомпресія чи встановлення циклу
Минулі знімки також легко доступні ...
... тож я можу поділитися ними як спільний доступ до Samba (за підтримки тіньової копії)
Знімки займають мінімальну кількість місця завдяки копіюванню під час запису (знімок без змін займає буквально кілька кіБ на диску)
Висока стійкість резервного копіювання: контрольні суми для файлів, очищення всіх даних та вбудована надмірність

Запитання:

Чи є якесь резервне рішення (у вигляді Bacula, BackupPC тощо), яке є, або його можна легко зробити, знаючи про файлову систему копіювання при записі?
Або мені потрібно використовувати домашнє rsyncрішення?
Що роблять люди із скриньками ZFS, призначеними для резервного копіювання, для створення резервної копії своїх Linux-машин?

— Хуберт Каріо
джерело

Не бачу cons! Одним із них було б те, що знімки Btrfs є еквівалентними лише покроковим резервним копіям (жодна фізична копія за резервну копію вашого файлу на диску). Що може мати важливе значення при вирішенні проблем з поверхнею диска. Зауважте, що ви можете примусити одне копіювання за допомогою вбудованої підтримки RAID1, включеної в Btrfs.

— vaab

1

@vaab: це pro- більше двох примірників насправді не потрібні, якщо у вас є контрольні суми та активно скребте FS, три, ймовірно, мають підтримку RAID6. Як я вже говорив, це налаштування для спеціальної системи резервного копіювання, а не "резервного копіювання" копій всередині FS на одному комп'ютері. Це було б "RAID не резервне копіювання" та "Знімки не є резервним копією". cp -aі rsyncдля цього ...

— Хуберт Каріо

Я також розглядаю резервне копіювання на btrfs, але я тільки думав rsync -a --delete /home/user /mnt/butterfs/backups/ && snapper create- окрім створення знімка після створення резервної копії, що ви маєте на увазі під знанням COW?

— unhammer

1

@unhammer: rsyncякщо --inplaceви не отримаєте кілька копій одних і тих же даних у віддаленій файловій системі. (rsync зазвичай копіює дані у тимчасовий прихований файл, а потім переміщує його по старому файлу; за допомогою файлової системи Copy-On-Write ви отримуєте дві копії на незмінних даних таким чином)

— Hubert Kario

5

За останній тиждень я здійснив обширний пошук чогось подібного. Я не знайшов рішення для виконання всіх 4 кроків. Існує чимало блогів домашніх користувачів, які намагаються створити резервні копії типу " rsync to btrfs ", і всі основні вікі-файли Btrfs висвітлюють, як виконувати знімки Btrfs.

Також є досить багато людей, які намагаються різними способами обертання знімків Btrfs . Однак ви - перша людина, яку я бачив, яка хоче обертати знімки на основі дискового простору. Я сам граю з btrfs-snap, який створює набір годинних, тижневих і місячних знімків, і це приємно і просто.

Проект Dirvish, здається, відповідає багатьом вашим вимогам. Деякі розробники намагаються інтегрувати Dirvish з Btrfs . Однак проект Dirvish здається трохи застопореним .

У цей момент часу ви випереджаєте криву.

— Стефан Ласєвський
джерело

Ну, я просто хочу, щоб рішення для резервного копіювання було без болю, як BackupPC: коли місця на диску мало, він просто видаляє старі дані (старі знімки). Поки я боявся, що я випереджую криву, це не так, як ZFS не був з нами останні кілька років ...

— Хуберт Каріо

3

За словами Аві Міллера (його розмова під час LinuxConf.AU) над btrfs відправленням / отриманням працює. Це буде швидше, ніж rsync, оскільки йому не потрібно переходити через каталоги, щоб знайти зміни у файлах. Я не знаю, чи є ще очікувана дата випуску.

Однак є утиліта, вбудована в btrfs-progs, яка перераховує кожен файл, який змінився між знімками / тощо. Btrfs subvolume find-new

— нудно
джерело

2

Я хочу зробити резервну копію на Btrfs, а НЕ з ...

— Hubert Kario

2

Я працюю над системою резервного копіювання ОС, схожою на BackupPC. Я про це думав. Те, що перешкоджає мені реалізовувати, це те, що ви не можете жорстко зв’язувати між підпунктами. Ви також можете створювати лише знімки підпунктів -> Один підтомник на кожного резервного клієнта. Таким чином, функція дедупликації рівня файлу не може співіснувати з таким підходом. І дедуплікація на рівні файлів зазвичай економить багато місця. Ви хочете створити резервну копію лише одного сервера?

Якщо у btrfs була дедуплікація на рівні блоку, цієї проблеми, ймовірно, можна уникнути, але це, як правило, і не надто повільно ...

Тоді такий підхід, звичайно, тягне за собою тісну інтеграцію з однією файловою системою (btrfs), тому це має бути необов'язковою особливістю.

Я запитую, тому що я замислююся над тим, щоб додати таку особливість корови, але не знаю, чи варто мені через недоліки, перелічені вище.

Редагувати: UrBackup підтримує резервні копії, як визначено в питанні зараз, з ядрами Linux> = 3,6 (з підтримкою перехресного перегляду посилання). Подивіться, як його налаштувати.

— UrOni
джерело

1

перехресне копіювання підшифрової посилання (виконане напівтвердим посиланням cp --reflink) або вже реалізовано, або буде впроваджено найближчим часом. Інтернет дедуплікаціі в FS або повільно (lessfs) або потребує величезну кількість оперативної пам'яті (ZFS) , тому в залежності від цього буде дійсно бути поганий особливістю програмного забезпечення резервного копіювання. У будь-якому випадку програмне забезпечення для резервного копіювання, орієнтоване на btrfs, матиме велику аудиторію, адже це, мабуть, буде наступним ext3.

— Хуберт Каріо

І ще одне: ви можете вирішити цю проблему, зберігаючи всі сервери в одному підпункті - ви можете повторно скопіювати копію між ними (для виведення), зберігаючи можливість знімка. Вам потрібно зробити знімок після вирахування, ви можете зробити знімок після резервного копіювання лише одного сервера! Резервні копії не займуть більше місця, якщо робити резервні копії по черзі. Крім того, ви можете створити резервну копію всіх серверів, вивести і лише потім зробити знімок. Таким чином ви можете створити резервну копію декількох серверів одночасно.

— Хуберт Каріо

Ти маєш рацію. Не думав про це. Для зручності ви можете передати символьне посилання на правильні знімки в іншому томі. Я також бачив виправлення для жорсткого посилання з перехресним томом (або --reflink), але він не схожий на те, що він зробив / або зробить його основним. Я справді загляну в це! Тепер ви, ймовірно, робите резервні копії через ssh. Мій проект спеціалізується на локальних мережах ... (

— автовідкриття

Так, патч живий і працює, на жаль, не в основному, я не знаю чому. Я намагаюся помилитися з Крісом Мейсоном про це. Що стосується вашого проекту, не соромтесь кинути мені рядок, я з радістю бета-тестую його (час дозволяє). Це впевнено звучить цікаво.

— Хуберт Каріо

Нарешті, цей патч висадився в основне ядро Linux 3.6. З перехресною перехресною пристроєм насправді було не так багато роботи. Я писав тут про це: urbackup.org/blog/?p=83 Код знаходиться у "наступній" гілці у сховищі git. Я зараз тестую це.

— UrOni

1

На сторінці вікі btrfs " Використовувати випадки " перелічені деякі інструменти: SnapBtr , Snapper, btrfs-time-machine, UrBackup.

Є пропозиція щодо вбудованого інструменту під назвою autosnap :

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

Autosnap - це не лише створення знімків, а й управління створеними знімками, оскільки тепер ви можете налаштувати автонабір для видалення знімків на основі простору файлової системи.

Однак станом на жовтень 2013 року у wiki зазначається, що "функція автонабору наразі не включена у версію btrfs".

— ігніс
джерело

1

У мене були подібні розчарування, тому я закінчив створити кілька сценаріїв, які я називаю snazzer . Разом вони пропонують знімати, обрізати, вимірювати та транспортувати через ssh (але на сьогоднішній день можна також надсилати / отримувати в / з локальних файлових систем). Вимірювання - це лише звіти про підписи sha512sum та PGP з моментальних контурів. Він не зовсім готовий до виходу, але я хотів би почути відгуки, якщо хтось встигне переглянути його на цій ранній стадії.

CLI-тільки на даний момент, але я взяв деякий час , щоб зробити його легко використовувати в системах з багатьма Btrfs подоб'емов - як правило , у мене є окремі подоб'емов для /var/cache, /homeі т.д. , які , можливо , повинні бути виключені з миттєвих знімків або мають більше / менше агресивні графіки обрізки.

Я боюся, що алгоритм обрізки суто приймає рішення щодо наявності набору знімків та їх дат, нічого не існує, щоб продовжувати обрізку, поки не буде виконано обмеження щодо використання диска - що ви видалите спочатку? Зменшити спочатку погодинну кількість або щодня? Можливо, скиньте найдавнішу, напр. щорічників? Різні розгортання матимуть різні пріоритети; і я не можу знати, чи це єдиний рівень резервного копіювання (у такому випадку ви не повинні скидати найдавніші резервні копії у випадку юридичних / страхових зобов’язань), або просто проміжний (у такому випадку ви, мабуть, ці щорічники архівували десь у безпеці в іншому місці).

Я додам підтримку ZFS та / або сумісність в якийсь момент; Це написано здебільшого в оболонці posix-ish і perl через сильне прагнення до "нульових" залежностей на даний момент, я сподіваюся, чистіша альтернатива реалізації python підтримується паралельно в якийсь момент.

— csirac2
джерело

якщо ваш FS не має великих розмірів і часто змінюється, є дуже мала різниця між тим, як зберігати знімок за місяць тому, і лише 1 на день з минулого тижня порівняно з одним на день протягом цілого місяця - btrfs потрібно буде зберігати різницю між теперішній стан і такий, що минув місяць тому - я просто зберігаю щоденники, але, оскільки його стиснуті та розрізнені я можу легко тримати їх на півроку назад - тоді скидання найстаріших гарантій звільнить хоч трохи місця

— Хуберт Каріо

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

— csirac2

@ csirac2 Ви підтримуєте сніг? Я шукаю такого типу рішення. Мене цікавить снізер, якщо він активно підтримується. Здається, GitHub не показує активності недавно ...

— MountainX

@MountainX Коли я не отримав багато початкових відгуків про snazzer, я якось втратив ентузіазм. Коли я почав писати це, насправді було лише хапання OpenSUSE і жменька скриптів оболонок / пітон, що плавали навколо для автоматизації btrfs. На той момент, коли я дійшов до спільного використання з усім світом, з'явилося багато інших варіантів, і я б сказав, що btrbk, здається, має багато імпульсу (хоч питання про відсутність автоматизованого тестування [можливо, виправлено зараз?]). Якби мені довелося це зробити ще раз, я, мабуть, співпрацював би з автором sanoid, щоб додати сумісність btrfs там. Зацікавлено почути ваші думки.

— csirac2