Linux mint резервное копирование папки

10 фев 2020, 14:36

Специально опробовал как пользоваться mintbackup — фирменного инструмента linux Mint для восстановления системы.
Порядок следующий из под работающей системы :

1. Запускаем mintbackup — Резервное копирование в меню , выбираем «Сделать резервную копию сейчас» —> «Вперед» —> «Вперед» —> «Применить» — происходить резервное копирование и в директорию по умолчанию : /Документы/Резервные копии/ . В папке «Резервные копии» создается пока один файл . -backup.tar — это копия всех ваших пользовательских файлов из /home/ «имя пользователя» .
Затем снова запускаем mintbackup — Резервное копирование , только выбираем Список программ и в той же директории : /Документы/Резервные копии/ в папке «Резервные копии» появляется еще один файл с именем . — packages.list — список программ.

2. Затем вставляем флешку отформатированную в FAT32 — ext2 , открываем два окна в файловом менеджере ( в одном открываем флешку — SBLIVE ( кликая по SBLIVE) , а в другом окне открываем папку «Документы» и перетаскиваем папку «Резервные копии» — на флешку SBLIVE ) данные копируются на SBLIVE — флешку и копия ваших данных создана .

3. Далее устанавливаем чистую систему Mint — как новую установку с liveCD . Получаем чистую , новую систему . Если требуется то дисковое пространство разбивает на увеличенные размеры под корень / , /home , /swap .

4. Затем данные с флешки копируете в папку «Документы» , как указано в 2. — выше , только наоборот.

5. Обновляем программное обеспечение через Менеджер обновлений.

6. Запускаем mintbackup — Резервное копирование и восстанавливаем файлы из резервной копии — используя «Восстановить» и затем снова запускаем Резервное копирование — восстановление программ. Происходит автоматический запуск восстановления всего программного обеспечения .
Все ярлыки на рабочем столе будут восстановлены, но запуск некоторых из их невозможен до переустановки программ.
Все программы которые были установлены через Менеджер программ будут восстановлены . Те программы которые вы ставили через терминал , могут быть восстановлены только вручную. Поэтому позаботьтесь над тем , чтобы все пакеты .deb , tar.gz и другие , а также команды их установки были бы сохранены у вас в листинге , например , любого текстового редактора для последующего переноса их в терминал . Эти листинги при создании резервной копии будут сохранены и восстановлены.
Настройки рабочего стола , системы восстанавливаются только вручную . Аплеты , Conky , Менеджер Conky , десклеты — восстанавливаются только вручную . Вплоть до переключения клавиатуры и настройки сети WIFI .
То есть это фирменное резервное копирование помогает в объеме работы с Менеджером программ и копирует содержимое всех ваших пользовательских директорий — скачанные файлы , фильмы , текст и тому подобное . И позволяет изменить размеры дискового пространства для системы Linux Mint при переустановке новой системы , если места , например , под корень / или /home не хватает .
Но для тех программ которые вы ставили через терминал или скачивали пакеты .deb и другие , а также настройки системы вы будете делать своими ручками. Пакеты .deb хотя и ставятся через Менеджер программ , например Yandex.deb , придется по ним кликать вручную.

Источник

Программы резервного копирования Linux

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

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

Программы для резервного копирования в Linux

1. Rsync

Утилита rsync не предназначена специально для резервного копирования, но её можно для этого использовать. Эта программа позволяет копировать файлы из одного компьютера на другой по протоколу SSH или своему собственному протоколу Rsync, но для последнего понадобиться чтобы на целевом компьютере был установлен сервер Rsync. Одно из преимуществ программы в том, что она позволяет не передавать через сеть всё содержимое файлов, а только те данные, которые изменились с последнего копирования. Это удобно для того чтобы не перегружать сеть лишними операциями. Никаких автоматизированных решений здесь нет, вам самим придётся настраивать что и куда копировать. Подробнее про Rsync читайте в этой статье.

2. AutoMysqlBackup

Если вам надо делать резервную копию базы данных MySQL, то для этого нельзя просто скопировать все файлы базы данных. Лучше скопировать нужные базы с помощью специального инструмента. К таким инструментам относится скрипт AutoMySQLBackup. С помощью него вы можете настроить регулярное резервное копирование вашей базы данных на другой сервер или в облако. Поддерживается ротация и удаление устаревших резервных копий.

3. Duplicity

Duplicity — это тоже небольшая утилита для резервного копирования файлов сервера, только в отличие от rsync она специально разработана для резервного копирования. Здесь тоже поддерживаются инкриментальные резервные копии и передача архивов по сети на другой сервер, но кроме того, поддерживается шифрование, а также восстановление из ранее сделанной резервной копии.

4. Rdiff-backup

Ещё одна небольшая утилита для резервного копирования, похожая на rsync. Она написана на Python и позволяет делать резервные копии только изменённых файлов. Кроме того, можно хранить резервную копию на другом сервере. На удалённый сервер можно записывать данные по протоколу rsync или ssh.

5. Bacula

Это уже не просто скрипт, а полноценная система резервного копирования, которую надо размещать на нескольких серверах. Она состоит из нескольких компонентов, каждый из которых имеет своё предназначение. Программа имеет открытый исходный код и предназначена, в первую очередь, для предприятий. Кроме полных резервных копий, так же как и в Rsync поддерживаются инкрементные, когда копируются только изменённые данные.

6. Backupninja

У программ, которые можно использовать для резервного копирования, таких как rsync, duplicity, tar и других нет конфигурационных файлов, с помощью которых можно было бы настроить и распланировать резервное копирование. И это понятно, они специально для этого не были предназначены. Backupninja — это оболочка для таких программ. Утилита позволяет настроить резервное копирование как файлов так и баз данных с помощью различных инструментов, но при этом хранит все конфигурационные файлы в одном месте — /etc/backups.d/. К тому же вместе у программой поставляется псевдографическая утилита ninjahelper, помогающая настроить всё почти в графическом интерфейсе.

7. Kbackup

Это небольшая графическая утилита для резервного копирования файлов разработанная для KDE. Позволяет выполнять как полные резервные копии так и архивировать только изменённые файлы. Копии хранятся только на том же компьютере, что и установлена программа, а автоматическое резервное копирование не поддерживается.

8. BackupPC

Это кроссплатформенная программа для резервного копирования, разработанная для больших предприятий. Для управлением резервным копированием используется веб-интерфейс. Можно делать как полные резервные копии, так и только для изменённых файлов. Можно запланировать автоматическое обновления или настроить уведомления о необходимости делать резервные копии.

9. Amanda

Amanda расшифровывается как Advanced Maryland Automatic Network Disk Archiver. Это тоже кроссплатфноменная программа для резервного копирования, созданная, в первую очередь, для предприятий. Она может располагаться на нескольких компьютерах, благодаря клиент-серверной архитектуре и сохранять резервные копии на другой сервер. Для создания резервных копий используются системные утилиты, в Linux это tar.

10. Back In Time

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

11. Box Backup Tool

Ещё один инструмент корпоративного уровня. Его можно установить на несколько машин и выполнять резервное копирование между ними. Программой можно управлять только с помощью командной строки. Поддерживаются инкрементальные копии, а также шифрование данных.

12. Luckybackup

Это ещё одна оболочка над утилитой rsync, только на этот раз с графическим интерфейсом. Она позволяет планировать автоматическое резервное копирование, выполнять полные копии или только синхронизировать изменения с сервером. Интерфейс утилиты интуитивно понятный и достаточно удобен в использовании.

13. Timeshift

Раньше мы рассматривали программы, предназначенные для резервного копирования отдельных файлов и каталогов, однако существуют программы предназначенные для полного копирования всех файлов операционной системы. К ним относится Timeshift. Программа имеет как графический так и консольный интерфейс и позволяет создавать резервные копии системы с помощью rsync или btrfs. Подробнее об её возможностях читайте тут.

14. Clonezilla

В отличие от Timeshift программа Clonezilla поставляется на отдельном образе и запускается из BIOS. Она позволяет создать резервную копию как Linux так и Windows потому что копирует весь диск побайтово и потом позволяет всё это восстановить. Подробнее о том как пользоваться Clonezilla читайте в отдельной статье.

15. Systemback

Утилита Systemback чем-то похожа на Timeshift. Она тоже позволяет создавать точки восстановления операционной системы и потом с помощью них восстанавливать работу вашего дистрибутива. Кроме того, с помощью утилиты можно скопировать систему на другой диск или создать LiveCD образ для будущего восстановления.

Выводы

Всегда помните, что резервное копирование очень важно, оно помогает предотвратить потерю данных. Существует огромное количество программ резервного копирования Linux, которые помогут регулярно копировать ваши данные.

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

Источник

Резервное копирование в Linux и других Unix-подобных ОС

«Люди делятся на две категории: одни уже делают бэкапы, а у других пока еще не отказывал жесткий диск», — неизвестный автор.

1. Введение

Тема резервного копирования рабочей Unix-подобной операционной системы (как правило, Linux) регулярно всплывает в списках рассылки и форумах, посвященных Linux. И неизменно кто-нибудь советует просто архивировать с помощью tar cvfz backup.tgz /bin /boot /etc . К сожалению, для создания правильной резервной копии понадобится больше усилий. В этой статье я расскажу о многих (возможно, не обо всех) трудностях и деталях, на которые следует обратить внимание при резервном копировании.

Имейте в виду, что это не инструкция к программе, поэтому не стоит слепо копировать приведенные здесь примеры; и это не исчерпывающее перечисление существующих программ для резервного копирования и примеров их использования. Также это и не пошаговая инструкция. Этот текст предназначен для тех, кто уже в достаточной степени разбирается в Unix-подобных системах. Тем не менее, важно полностью читать документацию конкретных инструментов, так как это поможет учитывать детали, которые иначе можно не принять во внимание.

Также учтите, что в этой статье в основном описывается процесс резервного копирования на внешние носители или удаленные машины. Если важна сохранность данных, я также настоятельно рекомендую использовать RAID -массивы. Хотя RAID и не поможет при пожаре, землетрясении или порче данных пользователем, это хорошая защита при выходе дисков из строя. Меня это не раз выручало. В дополнение не забудьте и об источнике бесперебойного питания.

Хотя мой личный опыт не выходит за рамки Linux, вопросы, обсуждаемые в этом тексте, должны (могут) относиться к большинству Unix-подобных систем.

2. Резервная копия — это не только данные

В правильном бэкапе сохраняются не только данные. Там содержатся и данные о данных: метаданные. Также копируются атрибуты конкретной файловой системы и файлы специальных устройств, необходимые для работы ОС. Жизненно важно, чтобы носитель резервной копии и программы для работы с ней могли обеспечить такое копирование. Например, категорически не рекомендую делать резервную копию файловой системы Ext3 (стандартная файловая система в Linux) на разделы, форматированные в FAT32/FAT16 (допотопная файловая система от Microsoft, все еще встречающаяся на USB-накопителях и подобных устройствах, хотя их можно, конечно же, форматировать в любую файловую систему). Этот раздел посвящен как раз метаданным и специальным файлам.

2.1. Метаданные файлов

На разделах с ФС Ext3 метаданные файлов включают в себя: время изменения файла, время изменения индексного дескриптора ( inode ), время последнего доступа, идентификаторы пользователя и группы, а также права доступа к файлам и каталогам. Если есть расширенные атрибуты, метаданных может быть намного больше, в основном за счет информации из списка управления доступом ( ACL , Access Control List). Чем больше данных будет скопировано, тем лучше. Разумеется, если не сохранить и не восстановить права доступа, это приведет к неработоспособности системы. Это верно даже для таких простых вещей, как mtime (modification time, время изменения содержимого файла). Например, в дистрибутиве Gentoo Linux mtime используется для того, чтобы определить, относятся ли файлы к конкретному пакету или они были изменены потом. Если не восстановить верное время изменения файлов, система управления пакетами будет полностью неработоспособна.

В зависимости от используемого ПО могут потребоваться разные шаги для сохранения всей этой информации. Например, при использовании tar с параметрами по умолчанию нельзя сохранить верную информацию о правах доступа. Если провести быстрый тест, может показаться, что это возможно, но это обманчивое впечатление. С параметрами по умолчанию tar распаковывает файлы с настройками umask (user file creation mode mask, маска режима создания пользовательских файлов) текущего пользователя. Если текущие настройки umask достаточно свободные, то файлы могут быть восстановлены со своими настройками прав, но при более жестких параметрах umask эти ограничения будут применены и к восстановленным файлам. Чтобы это предотвратить, tar надо использовать с параметром —preserve-permissions .

Информация о владельцах файлов может храниться двумя способами: в числовом и в текстовом виде. Многие программы для резервного копирования предпочитают текстовое представление для удобства чтения человеком, но при создании резервной копии всей системы это нежелательно. Вполне вероятно, что вы будете восстанавливать систему с помощью какого-нибудь Live CD, тогда как резервная копия создавалась на самой копируемой системе. При восстановлении файлы, принадлежащие пользователю bin , получат идентификатор (ID) файловой системы, основанный на данных файла /etc/passwd с Live CD. Если это будет, например, ID 2, но тот же идентификатор в восстанавливаемой системе присвоен пользователю daemon , то файлы, принадлежащие bin , будут принадлежать daemon . Поэтому всегда следует хранить информацию о владельцах файлов в числовом виде. Для этого в tar есть параметр —numeric-owner . В rdiff-backup существует аналогичный параметр —preserve-numerical-ids , добавленный с версии 1.1.0 по моей просьбе. В dar никогда не будет поддержки текстового представления. Мы обсуждали с автором этот вопрос, и он согласился с моими аргументами.

Некоторые программы для резервного копирования (например, tar и dar ) могут восстанавливать atime (access time, время последнего доступа) после чтения файлов во время создания копии. Это делается для того, чтобы копии максимально точно соответствовали оригиналу. Этой функцией следует пользоваться с осторожностью, так как восстановление atime изменяет ctime (change time, время изменения индексного дескриптора). С этим ничего не поделаешь, так как ctime невозможно установить принудительно. В man-странице dar говорится, что NNTP-сервер Leafnode при кешировании рассчитывает, что время последнего доступа восстановлено, но обычно очень редко требуется восстанавливать atime. По моему мнению, для любой программы предполагать, что значение atime восстановлено в резервной копии — это серьезный изъян. Время доступа может меняться произвольно, даже пользователем, не имеющим доступа на запись файла. К тому же программы для автоматического индексирования, такие как Beagle, могут изменять atime. Кроме того, изменение в ctime может вызвать срабатывание отдельных программ для защиты компьютера. Как уже говорилось, ctime нельзя установить принудительно, а значит, если у файла изменено значение ctime при неизменном со времени последней проверки mtime, этот файл мог быть заменен другим, обычно это свидетельствует о внедрении руткита. Следовательно, сохранять время доступа имеет смысл, только если вы абсолютно точно знаете, что делаете. По умолчанию dar сохраняет atime. Изменения, исправляющие такое поведение, уже внесены в CVS, и скорее всего появятся в версии 2.4.0. Для старых версий следует использовать параметр —alter=atime .

2.2. Специальные файлы

2.2.1. Ссылки

Ссылки бывают двух типов: символические и жесткие. Символическая ссылка, или симлинк, — это просто указатель на другое место файловой системы. Жесткая ссылка, или хардлинк — это дополнительный указатель для inode (индексного дескриптора).

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

Жесткие ссылки требуют несколько больше внимания. Как уже говорилось, жесткая ссылка — это в принципе второе (третье, четвертое. ) имя файла. Если у вас есть файл A и ссылающийся на него файл B, они ведут себя, как если бы у вас было два файла. Если оба файла по 1 ГБ, они будут занимать 1 ГБ на диске, но приложения будут считать, что они занимают 2 ГБ. Так как файл B — не просто ссылка на A, а другое имя для того же файла, можно безболезненно удалить файл A. Файл B не будет удален при удалении файла A.

Большинство приложений для резервного копирования поддерживают жесткие ссылки, но только если они все находятся в одном дереве каталогов. Если копировать каталоги /bin , /etc , /usr и т. д. отдельной командой cp -a для каждого, то информация о жестких ссылках не будет распознана и скопирована. Так как жесткие ссылки не могут указывать на файл в другой файловой системе, достаточно копировать и восстанавливать по одному разделу за раз. Например, если каталог /home вынесен на отдельный раздел, можно сделать отдельный архив с корневым каталогом / без /home и отдельный архив только с /home . Если создавать архив, включающий в себя все точки монтирования, понадобятся дополнительные действия, чтобы данные восстанавливались на нужных разделах. Если программе не мешают существующие каталоги, можно перед восстановлением данных создать точки монтирования с теми же именами в новой файловой системе. В противном случае должен помочь такой вариант: сначала восстановить данные на один раздел, а затем скопировать части на свои разделы с помощью cp -a . Не используйте mv для перемещения данных. Представьте, что будет, если программа аварийно завершится, не закончив работу.

В Linux и других Unix-подобных операционных системах широко используются жесткие ссылки, поэтому убедитесь на 100%, что целостность ссылок не нарушена.

2.2.2. Разреженные файлы

Разреженный файл (sparse file) — файл, в котором нули не записываются на диск как нули, а просто не размечаются. Благодаря этому, например, гигабайтный файл с большим количеством пустого места может занимать всего мегабайт. Такие файлы использует торрент-клиент Azureus.

В программах для резервного копирования поддержка разреженных файлов есть далеко не всегда. При использовании программы, не поддерживающей разреженные файлы, файл считывается как обычный. Данные в файле остаются те же, но он может занимать гораздо больше места. Будьте осторожны, резервная копия может не вместиться на предназначенный для нее диск при восстановлении, если разреженные файлы создаются как обычные.

Для файлов, загружаемых через торренты, это не слишком страшно, они так или иначе при загрузке будут заполнены данными. Но при наличии большого количества разреженных файлов, которые должны оставаться разреженными, необходима программа для резервного копирования с поддержкой разреженных файлов. Но в любом случае, даже если файл определен как разреженный, копия не будет размещена там же и так же, как оригинал, так как эту информацию нельзя получить. Вместо этого будет создан новый разреженный файл, в котором неразмеченные области будут использованы на усмотрение создающей его программы. Однако, это не должно стать проблемой. Не могу представить ситуацию, в которой это было бы важно.

2.2.3. Другие

Существуют и другие специальные файлы, такие как FIFO , именованные конвейеры (named pipes), блочные устройства и т. д. Они ничем особо не примечательны и большинство приложений знает, как с ними работать. Но надо обязательно указывать правильные параметры. Например, cp без параметра -a попытается скопировать данные именованного конвейера вместо того, чтобы воссоздать его.

Есть также и специальные каталоги: lost+found (в файловых системах Ext2/3/4). На самом деле это вообще не каталог, его невозможно создать программой mkdir . Вместо нее используйте mklost+found . Если не знаете, lost+found используется для хранения файлов, восстановленных программой e2fsck при повреждении файловой системы.

3. Что можно исключить

Чтобы сэкономить место на носителе с резервной копией, можно не сохранять некоторые каталоги. У меня в Gentoo Linux это /usr/portage/ и /var/tmp/portage .

Есть еще особые файловые системы, монтируемые в корневую, которые динамически создаются при загрузке, их не надо сохранять. В моей системе это каталоги /sys , /proc , /lost+found , /media (в котором только динамически создаваемые каталоги для съемных носителей) и /dev (потому что я использую udev ). Я также не сохраняю /mnt , но в других системах может быть необходимость в его резервном копировании.

4. Данные приложений

Создавая резервную копию работающей системы, не следует забывать о программах, которые могут изменить свои данные во время копирования. Удачный пример — это базы данных, такие как MySQL или PostgreSQL, а также данные почтовых программ (файлы mbox более уязвимы, чем maildir ). Файлы данных (обычно хранящиеся где-нибудь в /var ) могут быть подвержены изменениям в работающей системе. Это может быть вызвано обычными операциями или автоматической очисткой базы данных. Никогда не полагайтесь на файлы с данными работающей базы данных, LDAP-сервера, репозитория Subversion или любых подобных программ, которые вы используете.

Если остановить работу этих программ перед резервным копированием не представляется возможным, запланируйте задания по периодическому сохранению дампов базы данных (с помощью pg_dump для PostgreSQL, slapcat для OpenLDAP, svnadmin dump или svn-backup-dumps для Subversion и т. д.) в файлах с пометкой о времени создания. Затем можно сделать резервные копии этих файлов, это должно быть безопасно. Везде, где возможно, пользуйтесь «родными» утилитами для создания дампов, такими как pg_dump и slapcat для PostgreSQL и OpenLDAP соответственно.

Создание запланированных дампов всегда полезно, независимо от ситуации. При внезапном повреждении данных останутся дампы предыдущих состояний базы и не все будет потеряно. А если дамп хранится в локальной файловой системе, не придется мучиться с поиском в резервных копиях, когда возникнет необходимость восстановить базу данных (или иные данные приложений).

5. Основные меры предосторожности

В этом разделе приведены некоторые меры предосторожности и принципы, о которых лучше не забывать.

5.1. Инкрементное резервное копирование и mtime

Некоторые утилиты для резервного копирования поддерживают инкрементные копии, то есть копируют только данные, изменившиеся со времени последнего бэкапа. Отличный пример — rdiff-backup , он кроме этого ничего и не поддерживает. Будьте осторожны с инкрементным копированием и выясните, как программа определяет, изменились ли данные. Лучше всего — проверка контрольной суммы, но она занимает много времени. На втором месте надежный и быстрый способ — проверка ctime. Правда, файловая система тоже должна поддерживать ctime, но большинство систем это могут. Исключение — файловые системы, которые вы вряд ли будете использовать (например, FAT32).

Некоторые утилиты используют для отслеживания изменений в файлах только mtime или комбинацию mtime + размер. Это ненадежный метод. Например, у образов дисков, смонтированных как петлевые устройства с помощью losetup , не меняется mtime при монтировании устройства и записи на него. Вот пример из моей личной практики: я сделал образ диска, требующего серьезного исправления файловой системы, с помощью ddrescue . Для начала я решил сделать ежедневный бэкап. Мне пришло в голову проверить, изменяется ли mtime файла образа диска при записи на смонтированное петлевое устройство, потому что были подозрения, что монтирование не воспринимается системой как открытие файла. Подозрения подтвердились. Чтобы файл попал в резервную копию, приходилось сначала изменить его время модификации с помощью touch .

Еще один небольшой пример — редактирование ID3-тегов в программе Easytag. В настройках Easytag есть параметр «Сохранить время модификации файла». Если размер файла при этом не изменится, например если изменить один символ в теге, время модификации и размер будут идентичными и изменение файла не будет замечено.

В rsync есть возможность на самом деле проверять, изменился ли файл, но это очень долгий процесс. Например, сканирование моего каталога /home на наличие измененных файлов занимает больше времени, чем создание полной резервной копии без сжатия с помощью dar . Более подробную информацию вы найдете в разделе 6.4 ниже.

Конечно, вы можете пренебречь риском подобной ошибки с определением изменений (так как шансы малы) и получить преимущество за счет прироста скорости. Лично мне не нравится, когда я могу себе представить сценарий, при котором программа не выполняет своих функций, но пока мирюсь с этим и использую rdiff-backup для некоторых разделов.

5.2. Резервное копирование на другую файловую систему

Просто копировать данные на другую файловую систему — пожалуй, не лучшее решение. Команды cp -a может быть вполне достаточно для ваших нужд (при условии, что копирование происходит в файловую систему с поддержкой всего, что есть в исходной файловой системе и, в случае cp , если не используются расширенные атрибуты). Меня заботит другое: слишком легко случайно изменить файл или его метаданные, открыв и сохранив его. Надежнее сохранять данные в архивах, как это делают tar или dar .

Так как rsync тоже просто сохраняет метаданные в файловой системе, эта опасность относится и к rsync .

Пользуясь информацией из этой статьи, вы сможете решить для себя, мешает вам это или нет. В этом подходе есть и определенные преимущества, такие как возможность быстро найти и скопировать отдельный файл из резервной копии.

5.3. Размер архива

У многих файловых систем (или сетевых протоколов) есть серьезные ограничения на размер файла. При резервном копировании с помощью программ, создающих архивы, надо учитывать размер архива. Как правило, лучше ограничивать размер двумя гигабайтами (или, на всякий случай, чуть меньше). Файлы такого размера можно сохранять в файловых системах ISO DVD и FAT32. Я предпочитаю размер в 650 МБ, чтобы можно было записать файлы на 74-минутные компакт-диски.

Даже если вы не собираетесь хранить резервные копии на подобных файловых системах, все равно лучше разделять архивы на части, чтобы иметь возможность записать их на CD или DVD, если понадобится.

5.4. Восстановление

Восстановление из резервной копии так же важно, как и ее создание. Надо изучать man-страницы как для выбора правильных параметров резервного копирования, так и для восстановления. Я считаю, хорошая программа для резервного копирования должна либо иметь тщательно подобранные параметры по умолчанию, либо сохранять параметры, выбранные при создании резервной копии, в архиве или в метаданных, чтобы использовать их и при восстановлении.

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

6. Программы рекомендуемые и не рекомендуемые, примеры использования

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

Иногда указываются именно GNU-версии приложений, стандартные для Linux, они могут принципиально отличаться от классических версий, об этом не следует забывать.

6.1. Dar

Прежде всего — предупреждение. Настоятельно рекомендую пользоваться версией 2.3.3 (последний стабильный выпуск на момент написания статьи) или более новой, так как в ней исправлена серьезная ошибка. Подробный отчет можно прочитать в новостной рассылке dar .

Dar — хорошо продуманная программа, в ней предусмотрены решения для классических проблем. Например, она поставляется вместе со статически скомпилированным бинарником, который можно скопировать на первый диск с резервной копией. В dar поддерживается автоматическое разделение архивов на тома и есть возможность отдельно указать размер первого тома, чтобы оставить место на первом диске, например, для создания загрузочного CD. Также можно запускать какую-нибудь команду между созданием томов, так что можно записывать их на CD, вычислить информацию для контроля четности и т. д. И, что очень важно, параметры по умолчанию хорошо подобраны за исключением, пожалуй, сохранения atime (см. выше).

Я использую такую команду для сохранения своей системы на внешнем USB-диске примерно раз в неделю с помощью dar 2.2.6 (параметры, относящиеся к конкретной машине, удалены или слегка абстрагированы).

С помощью параметра —execute я вычисляю информацию для контроля четности с помощью par2 . Передаваемые программе par2 тайные знаки превращаются в имя создаваемого par2 файла и имя тома архива. Параметр —alter=atime уже обсуждался выше; —empty-dir сохраняет в архиве пустые каталоги для всех исключенных из бэкапа каталогов; -an и следующий за ним -Z по нечувствительной к регистру маске указывают, какие файлы не следует сжимать. Степень сжатия указывается с помощью -z6 . Для исключения каталогов используется —prune . Остальное должно быть понятно.

Кроме того я обычно ежедневно создаю с помощью dar резервную копию /home без сжатия. Размер получается около 6 ГБ, копирование занимает около 10 минут. Вполне приемлемо, на мой взгляд. Но по мере увеличения размера домашнего каталога я переключаюсь на rsync и затем на rdiff-backup и мирюсь с потерями времени на проверку изменений.

Восстановление из архива dar должно быть безопасно с параметрами по умолчанию (очень важный аспект, по моему мнению), но на всякий случай прочитайте man-страницу.

6.2. GNU tar

GNU tar может все, что может потребоваться для надежного резервного копирования (хотя, надо заметить, я не знаю, насколько хорошо там поддерживаются расширенные атрибуты и поддерживаются ли вообще). Однако следует быть внимательным и не забыть о параметре —numeric-owner . Это же, возможно, касается и параметра same-owner , но быстрый тест и просмотр руководства дают понять, что параметр —preserve-permissions (который включен по умолчанию для пользователя root ) это подразумевает. Если вы вдруг забыли использовать параметр —numeric-owner для команды резервного копирования, его можно задать в процессе восстановления. Его использование при резервном копировании должно, по идее, исключить необходимость его указания при восстановлении, так как с этим параметром tar не сохраняет в архиве имена владельцев в текстовом виде.

Читайте также: Чем писать диск с mac os

В tar также нет достойных средств для разделения на тома. Встречаются рекомендации использовать split , но это не слишком удобно. Чтобы использовать split , сначала надо выделить место для создания архива, потом место для сохранения разделенных частей. Восстанавливать файлы тоже хлопотно, сначала надо соединить сегменты с помощью cat , и только потом можно будет распаковать архив.

Еще на одну проблему tar мне указал один из читателей. В версии 1.15.1 программа повреждала разреженные файлы размером более 4 ГБ . В современных версиях tar (1.20 и выше) вроде бы нет этой проблемы, но лучше лишний раз проверить.

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

6.3. Rdiff-backup

При оценке надежности rdiff-backup надо учитывать метод отслеживания изменений, который применяется в этой программе. Если часто приходится работать с образами дисков, прочитайте пример, приведенный выше. Как-то раз мы обсуждали с автором альтернативный способ отслеживания изменений, но ему было некогда и дискуссия так ни к чему и не привела. Возможно, в будущем в программе появится надежный способ отслеживания изменений на основе контрольных сумм или ctime. Учтите, что rdiff-backup сохраняет контрольные суммы в своих метаданных с версии 1.1.1 (05.11.2005), но до сих пор не использует их для отслеживания изменений в файлах (на момент версии 1.2.1, 24.08.2008).

Кроме того, при восстановлении с помощью rdiff-backup из полной копии системы из-под другой ОС, например Live CD, не забывайте указывать параметр —preserve-numerical-ids , иначе у файлов будут неправильно указан владелец. Об этом слишком легко забыть (проверено на собственном опыте).

Между тем, если вы полностью уверены, что вас не коснется проблема с mtime, описанная выше, например в /home , можно смело пользоваться этой программой. Не исключено, что мои опасения покажутся вам преувеличенными, и вы можете копировать всю систему несмотря ни на что. Я решил, что опасность не слишком велика и пользуюсь rdiff-backup . Это очень надежная программа и одна из лучших для инкрементного копирования, на мой взгляд.

6.4. Rsync

Моя главная проблема с rsync — то, что метаданные программы создаются заново в целевой файловой системе. Это не только ограничивает использование целевой файловой системы, но и вообще странно, о чем написано выше. Кроме того, rsync — одна из тех утилит, которые проверяют наличие изменений в файлах по комбинации mtime и размера. И, так как ее параметры для надежной проверки наличия изменений в файлах ( —ignore-times и особенно —checksum ) замедляют работу программы, dar без сжатия может быть предпочтительнее. Разумеется, только при резервном копировании на быстрый локальный носитель.

Здесь важно отметить, что rsync не сохраняет файлы метаданных, и поэтому сравнивает mtime и размер файла с копией. Это означает, что только при использовании параметра —times для сохранения mtime файлов проверка изменений не сработает, как было описано ранее.

У rsync есть особый ключ —archive , специально предназначенный для сохранения всех метаданных. Правда, этого параметра все равно недостаточно. Например, по умолчанию не сохраняется информация о жестких ссылках, потому что это слишком медленно. Также не сохраняются жесткие ссылки, расширенные атрибуты и списки управления доступом. Поэтому надо дополнительно указывать —hard-links , —acls и —xattrs ( rsync поддерживает расширенные атрибуты с третьей версии, кажется). Также желательно добавить параметры —sparse и —numeric-ids по описанным выше причинам. Я бы добавил еще —delete —delete-excluded —delete-after , чтобы в резервную копию не попали старые файлы. Параметр —delete-after необходим, так как иначе в случае сбоя в процессе копирования файлы, переименованные после создания последней резервной копии (старый файл удален, новый создан), будут удалены до того, как новый файл скопирован. Лучше сначала скопировать новый файл, а затем удалить старый.

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

Некоторое время назад вышла третья версия rsync . Там появились интересные новые возможности, такие как поддержка списков управления доступом и расширенных атрибутов. Могут возникнуть проблемы с определением изменений, но, особенно начиная с третьей версии, программу стоит использовать (возможно, только для резервного копирования отдельных частей), потому что она весьма эффективна и продуманна.

6.5. GNU cp

Я всегда думал, что cp -a сохраняет все, что нужно, но оказалось, что информация списков управления доступом и, возможно, расширенных атрибутов, вообще не копируется. Я не пользуюсь списками управления доступом, поэтому не могу привести каких-либо тестов, так что пробуйте сами.

6.6. Clonezilla

Clonezilla — специализированный Live CD для создания образов файловых систем различных типов, в том числе NTFS. За исключением некоторых странностей интерфейса, это прекрасно спроектированная программа. Она оправдывает все ожидания, например использует dd для резервного копирования MBR и области между MBR и первым разделом. Она даже запускает sync по завершении. Такое впечатление, что программа читала эту статью 🙂 И, возможно, самое важное: можно извлекать компакт-диск при выключении или перезагрузке!

6.7. Другие инструменты клонирования разделов

Программы для клонирования разделов, такие как g4u , partimage , clonezilla (или dd . ) могут быть очень удобны, но у них (в основном) есть один существенный недостаток: они (зачастую) требуют, чтобы данные восстанавливались на идентичный диск и (или) такие же разделы. Если диск сыплется и надо найти новый, это может быть сложно.

Однако это не всегда так. Недавно я скопировал с помощью dd целый диск на другой (на 1 ГБ больше) командой dd if=/dev/sda of=/dev/sdb . На новом диске теперь есть неразмеченная область, но он работает отлично. Windows XP, установленная на этом разделе, загружается с нового диска, хотя Windows XP капризна в таких делах. В любом случае, восстановление на меньший раздел будет проблематично. Иногда можно импровизировать, но лучше этого избегать. Если вы собираетесь использовать этот метод резервного копирования, лучше удостовериться, что запасной диск имеет достаточный размер. Этого можно добиться, предполагая, что размер дисков со временем увеличивается, или пользуясь небольшими разделами (но не слишком маленькими, чтобы не допустить фрагментации).

Не слишком «умные» программы для клонирования, такие как g4u или dd , тратят огромное количество времени, так как копируют каждый блок файловой системы, в том числе и незанятые. И, если эти незанятые блоки заранее не записаны нулями, готовый образ получается очень большим.

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

7. Автоматизация

При автоматизации резервного копирования есть один важный момент, о котором не следует забывать: синхронизируйте дисковые буферы как можно чаще, и желательно подождать секунду-другую после синхронизации, чтобы кеш устройства был записан непосредственно на диск. Некоторые носители раньше времени рапортуют, что сбросили кеш на диск, поэтому не всегда можно рассчитывать, что данные из энергозависимого кеша были записаны, и лучше немного подождать после того, как sync закончит работу.

Вот пример, демонстрирующий важность этого момента: предположим, что мы делаем резервную копию с помощью tar . Сначала делаем новую копию, затем удаляем старую. Если дисковый кеш не синхронизирован и во время удаления старой копии отключилось питание, может выйти так, что и старая, и новая копии будут повреждены. Мне говорили, что это бессмысленно, потому что данные в кеше упорядочены последовательно и удаление после начальной команды копирования сначала вызовет запись кеша. Это не совсем так, особенно если у вас диск с NCQ / TCQ , а это большинство современных дисков. Весь смысл записи кеша в том, чтобы подготовиться к записи вне очереди.

Я рекомендую запускать резервное копирование примерно так:

Запуск sync в конце тоже важен, чтобы в случае сбоя не повредить данные при размонтировании, если носитель, например, будет физически отключен.

8. Копирование файловой системы

Если есть желание создавать снимки всей файловой системы, имеет смысл использовать логические разделы, созданные с помощью LVM . Логические разделы позволяют создавать атомарные снимки всего раздела. Лучшая резервная копия — это копия на уровне файловой системы или ниже, так как позволяет сохранить все данные и метаданные, поэтому это очень надежный способ резервного копирования.

Тем не менее, я никогда не пользовался LVM и поэтому не могу рассказать ничего полезного по этому поводу. Самостоятельно изучите документацию, чтобы выяснить, насколько вам это действительно подходит.

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

9. Выбор файловой системы

Хотя это несколько выходит за рамки предмета статьи, хотелось бы сказать пару слов и о выборе файловой системы. Многие отдают предпочтение ReiserFS, а не Ext3, из-за ее новизны или незначительных отличий. Ext3 — файловая система по умолчанию в большинстве дистрибутивов Linux. Я рекомендую оставаться на ней, если нет особых причин использовать какую-то другую. В ReiserFS, например, есть логическое журналирование. Есть информация , что это может быть опасно в случае аварийного отключения питания. К тому же, сам Ганс Райзер говорил (или говорят, что говорил), что ReiserFS оптимизирована для быстродействия, а не безошибочной работы.

Даже в новой файловой системе Ext4 есть потенциальные проблемы, связанные с отложенным размещением . В Ext3 это был необязательный параметр ( data=writeback ), но в Ext4 он используется по умолчанию. Отложенное размещение в случае Ext4 означает, что данные записываются на диск примерно раз в минуту, тогда как метаданные записываются гораздо чаще, примерно каждые несколько секунд. Линус Торвальдс сказал: «Записывать данные позже, чем метаданные, ссылающиеся на них — значит делать все буквально шиворот-навыворот. Только идиот мог принять такое решение. Безо всяких «но», «если» или «может быть». В ext3, по крайней мере, это не было режимом по умолчанию».

В любом случае, я считаю, что любую файловую систему надо изучить, прежде чем использовать. Возможно, Ext3 ничем не выделяется, но это не так уж плохо. В разделе «Ссылки» можно найти дополнительную информацию по теме.

Источник

Linux mint резервное копирование папки

СОЗДАТЬ ПОЛНУЮ РЕЗЕРВНУЮ КОПИЮ СИСТЕМЫ С ПОМОЩЬЮ ТЕРМИНАЛА В _ Linux Mint / Ubuntu _