LINUX.ORG.RU

Как сделать бекап HDD носителя (RAID)

 , ,


0

2

Хай, Есть простая и важная задача.

Есть HDD носитель, важная рабочие данные. Как можно сделать его полный бекап? Есть вроде несколько вариантов: а) Ручками :) б) Вроде делать полный образ носителя 1 файлом, и хранить где угодно. Уточните каким софтом или методом делать. в) Взять другой HDD хоть Sata диск или наверное лучще идейтичный носитель и сделать RAID, Sync - подскажите туториал.

Если есть ещё варианты, подскажите :)

Спасибо

  • tar (если данных много, то долго);
  • rsync (если данных много, то долго);
  • snapshot в файл и/или на другой диск (если такой инструментарий предоставляется, скорость зависит от реализации);
  • dd (только оффлайн, крайне долго);
  • dump (если доступно, желательно оффлайн, долго).
mord0d ★★★ ()
Ответ на: комментарий от mord0d

Интереснно, но всё-же какой вариант выбрать. TAR и подобное файлами чтото не нравится, нужен бекап такого вида что если понадобится использовать бекап, потом леко его синхронизовать с основным накопителям, поэтому я упомянул о RAID.

Оффлайн - ну да работа будет проходить исключительно через USB (если я правельно понял пометку).

Сколько ждать процесс бекапа не проблема, главное чтобы было надёжно и просто в исопльзовании.

Буду делать хотябы 1 раз в неделю.

Ещё интересует не повредит ли какой-нибудь вариантов решения сам накопитель тк он SSD, 500Gb., где занято прим. 300Gb.

Спасибо.

Hooder ()
Последнее исправление: Hooder (всего исправлений: 2)
Ответ на: комментарий от Hooder

всё-же какой вариант выбрать

Подходящий под задачу.

не нравится

«Тебе шашечки, или ехать?»

нужен бекап такого вида что если понадобится использовать бекап, потом леко его синхронизовать с основным накопителям

Тогда только средствами самого RAID или файловой системы на нём.

поэтому я упомянул о RAID

Тогда только средствами RAID (но если ты задаёшь такие вопросы, то их, подозреваю, нет?).

Оффлайн - ну да работа будет проходить исключительно через USB (если я правельно понял пометку).

Нет, это значит, что файловые системы на RAID придётся отмонтировать.

Сколько ждать процесс бекапа не проблема

На очень больших объёмах данных можно и на несколько суток бэкап затянуть.

Ещё интересует не повредит ли какой-нибудь вариантов решения сам накопитель тк он SSD, 500Gb., где занято прим. 300Gb.

Это диск с которого будут бэкапиться данные, или на который они будут бэкапиться?

dd может повредить диск назначения только если писать на блочное устройство напрямую, а не в файл, и то только в некоторых случаях. В остальном всё упирается в ресурс диска.

---

По итогам твоих ответов могу рекомендовать rsync. Если бэкап долгосрочный (или нужно хранить предыдущие итерации) — паковать предыдущий бэкап в tar, и уже после обновлять дерево rsync’ом.

mord0d ★★★ ()

Рейд тут вообще не при делах.

Для пофайлового бекапа лорчую rsync.

Если нужна история изменений, rdiff-backup.

Можно снимать полную поблочную копию через dd (впрочем cat тоже сработает), но тогда бекапится и свободное место (при помощи dumpe2fs свободное можно пропустить). Блочная копия каждый раз копируется вся даже если с прошлого раза изменился один файлик.

К слову, можно написать правило для udev/systemd которое будет бекапить диск сразу при подключении.

legolegs ★★★★★ ()
Ответ на: комментарий от mord0d

dd может повредить диск назначения только если писать на блочное устройство напрямую, а не в файл, и то только в некоторых случаях

Херню ляпнул.

anonymous ()

Бэкап лучше делать в файл и хранить на отдельных носителях каждую из последовательных версий. Если HDD 500ГБ, то покупаешь минимум два SATA SSD по 1ТБ. И периодически на каждый SSD делаешь по-переменно полную копию данных с HDD (при этомм программы, работающие с данными на HDD должны быть закрыты — чтобы обеспечить логическую полноту и целостность информации на носителях).

Важно также периодически проверять работает ли сохранённый бэкап — на другой машине. А то окажется, что все затраты впустую.

iZEN ★★★★★ ()
Ответ на: комментарий от mord0d

rsync (если данных много, то долго)

С какими объемами ты имел дело? У меня 125 гигов фотографий забэкапилось с основного диска на старый SATA2 минут за 20-30, точно не замерял. Это вполне нормальная скорость. rsync показал среднюю скорость 80 МБ/сек, но иногда подскакивало и больше ста. До 120, насколько помню.

anti_win ★★ ()
Ответ на: комментарий от anti_win

Если файлы мелкие и в большом количество, то на НЖМД действительно небыстро идёт первоначальное сравнение. Впрочем, это всё равно быстрее, чем посекторная копия.

legolegs ★★★★★ ()
Ответ на: комментарий от anonymous

dd может повредить диск назначения только если писать на блочное устройство напрямую, а не в файл, и то только в некоторых случаях

Херню ляпнул.

Во-первых это актуально только для SSD, во-вторых это зависит от контроллера и данных.

mord0d ★★★ ()
Ответ на: комментарий от anti_win

С какими объемами ты имел дело?

В основном с бинарными, несжимаемыми.

У меня 125 гигов фотографий забэкапилось с основного диска на старый SATA2 минут за 20-30, точно не замерял.

На последующих проходах скорость возрастает за счёт непередачи неизменённых данных.

mord0d ★★★ ()
Ответ на: комментарий от legolegs

А у rdiff-backup последний снимок - это простые файлы.

Слабое утешение, когда это почти единственная стоящая фича. Ни шифрования, ни аутентифицируемого шифрования, ни нормальной дедупликации, ничего по сути. И наверняка прибито гвоздями к POSIX-совместимым ФС.

anonymous ()
Ответ на: комментарий от anonymous

Ни шифрования, ни аутентифицируемого шифрования

Есть другие средства

нормальной дедупликации

Не всем данным она нужна.

И наверняка прибито гвоздями к POSIX-совместимым ФС.

Нет. Если ФС не поддерживает какие-то символы в именах файлов, права, владельца - эта инфа записывается иначе.

legolegs ★★★★★ ()