Debian rsync backup восстановление
Обновлено: 08.07.2024
Если у тебя на компьютере не хранится дорогих тебе фотографий или
документов, эта заметка будет тебе не интересна. Если ты уже делаешь резервные копии и механизм работы с ними тебя полностью устраивает, эту заметку тоже лучше пропустить. Если ты считаешь, что хорошо разбираешься в linux, то вряд ли почерпнёшь в ней что-то новое. Для остальных — делюсь .
Зачем нужно делать резервные копии важных данных?
Как сказал Воланд в «Мастер и Маргарита», ужасно не то, что человек смертен, а то, что он внезапно смертен. То же самое верно относительно жёстких дисков. У меня за мою жизнь сдохло, кажется, всего 2 НЖМД, один сдох внезапно (очень ценные данные были утеряны), другой — почти внезапно (удалось восстановить часть данных), ситуация среди моих знакомых в среднем отличается не сильно. Статистика смерти винтов есть куда менее субъективная, от гугла — в среднем винт живёт несколько лет, и в 60% случаев винты дохнут внезапно, даже для S.M.A.R.T.
Кроме аппаратных, есть ещё и программные причины утери данных — однажды вирус WIN95.CIH снёс первые несколько мегабайт диска, включая FAT, что привело к полной недоступности данных. Ушёл месяц яростного программирования и лазанья с DiskEdit, чтобы в условиях отсутствия Интернета разобраться со структарами FAT-а и восстановить их. Однажды Patrition Magic завис при переносе раздела. Однажды при работе
Partition Magic-а отключили электричество в щитке на лестничной площадке. В последних двух случаях важные данные не потерялись — но это просто везение. Если вы подключены к сети, то есть вероятность взлома и уничтожения важных данных злоумышленником. От такого рода повреждений RAID-массив уже не спасёт.
Как оценить целесообразность бэкапа?
Есть такое понятие, как жёсткость риска — это вероятность возникновения риска, помноженная на стоимость риска в деньгах. Стоимость риска в данном случае — это то, сколько ты готов был бы заплатить денег за восстановление всей утеряной информации. Оценим вероятность риска снизу. Оценить я могу только аппаратные сбои, ибо остальной статистики у меня нет, да и этой причины для меня уже
было достаточно. Вероятность смерти жёсткого диска за 3 года — не менее 24% в любом случае, независимо от того, новый он или нет. Вероятность, что смерть будет внезапной, как я уже писал, 60%. Итого вероятность внезапной смерти за 3 года — 14%. Если используются два ЖД без зеркалирования, вероятность смерти хотя бы одного из них за этот период — 26%.
Конечно, нужно учитывать и ценность данных на этих дисках — у меня 2 ЖД с ценными данными (потеря любого фатальна) и один с музыкой и фильмами — расстраиваться о утери коллекции избранной мною музыки буду, но переживу.
Когда-то я был студентом и порой жил на 600 рублей в месяц, но теперь я могу позволить себе некоторые вложения в безопасность данных. Сегодня я купил внешний (USB) жёсткий диск на 320 гигабайт, и это удовольствие обошлось мне в 3000 рублей. Почему жёсткий диск? Потому, что данных у меня много — только дорогие моему сердцу фотки занимают гигабайт этдак 40. Да и времени на это тратить много не хочется и хотелось бы, не сортируя всё то, что накопилось за многие года на «важные — неважные» забэкапить вообще всё, кроме музыки и фильмов. Почему внешний? Возможность хранить отдельно от компьютера на случай кражи (хотя это более актуально для ноутбуков), не присоединённым к компьютеру (на случай ошибки, фатальной для данных).
Безопасность.
Я не параноик, но жёсткий диск содержит данные, безопасность которых нужна не только мне — например, совсем не обязательно попадать в руки посторонних фотографиям знакомых девушек в стиле «ню». Соответственно, диск шифруем — я зашифровал весь. В debian всё делается из коробки за несколько минут и потому я нисколько не сомневаюсь, что смогу потом с лёгкостью эти данные восстановить, главное — не забыть записать используемый каскад алгоритмов и подсказку к паролю на бумажке и хранить её в коробке с винтом. Использование сторонних коммерческо-крякнутых средств я бы очень не рекомендовал.
Приступаем.
Я, не долго думая, решил забэкапить все неиспользуемые (но те, которые на всякий случай лучше не терять) разделы целиком, для теста взял раздел с когда-то установленным WIN98:
$ sudo rsync --archive --one-file-system /etc /home /root --delete /mnt/backup/rsync/`date +%F--%H-%M`
Нужно сохранить несколько последних бэкапов? Пожалуйста, используем то, что параметр --link у cp создаёт жёсткую ссылку на файл вместо его копирования.
$ sudo rsync --archive --one-file-system /etc /home /root --delete /mnt/backup/rsync/latest/
$ sudo cp --archive --link /mnt/backup/rsync/latest/
/mnt/backup/rsync/`date +%F--%H-%M`
Хочется увидеть различия с бэкапом? «Эмулируем» копирование текущего состояния в состояние бэкапа.
$ sudo rsync --archive --dry-run --verbose --one-file-system /etc /home /root --delete /mnt/backup/rsync/latest/
Хочется увидеть различия между бэкапами? Аналогично.
Есть множество способов выполнить резервное копирование отдельной информации или целых серверов. Я хочу рассказать о самом простом способе полного бэкапа сервера и переноса его на другое железо, если будет такая необходимость. Делается все это очень просто, без лишних телодвижений с помощью бесплатного Veeam Agent for Linux FREE.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.Введение
Ранее я уже неоднократно рассматривал вопрос резервного копирования данных или целых серверов linux. Конкретно в этих статьях:
Забэкапить сразу весь сервер можно, например, с помощью Duplicity. Но вот восстановить его на другом железе будет не так просто. Помимо данных нужно будет, как минимум, позаботиться о разметке диска, установке загрузчика. На это необходимо затратить некоторые усилия и немного разбираться в теме initramfs и grub. Сам я не очень разбираюсь в нюансах работы этих инструментов и очень не люблю с ними возиться.
Некоторое время назад появился отличный бесплатный продукт для бэкапа всего сервера целиком. Речь идет о Veeam Agent for Linux FREE. С его помощью можно сделать полный backup сервера, положить его куда-нибудь по smb или nfs, потом загрузиться с live cd и восстановить из бэкапа на другом железе.
Сразу расскажу о некоторых нюансах работы бесплатной версии, с которыми столкнулся в процессе эксплуатации замечательного продукта от veeam.
- Бэкап можно сделать либо всего сервера сразу, либо отдельного диска, либо отдельных папок и файлов. При выборе бэкапа всего диска или сервера, нельзя задать исключения для отдельных папок или файлов. Это очень неудобно, но увы и ах, таков функционал. Исключения можно сделать только если вы делаете бэкап на уровне папок.
- Бэкап можно положить локально на соседний раздел, если делаете резервную копию раздела, локально в папку - если делаете бэкап файлов и папок. Если бэкапите всю систему целиком, то удаленно по smb и nfs. К сожалению, по ftp или sftp программа не работает.
В качестве хранилища для архивов может выступать репозиторий Veeam Backup & Replication. Но я не рассматриваю этот вариант, так как в данном случае использую только бесплатное решение.
Мне очень хотелось настроить резервную копию всего сервера на Яндекс.Диск, но, к сожалению, у меня это не получилось из-за технических ограничений. Яндекс.Диск подключается к системе через webdav. Для того, чтобы сделать резервную копию всей системы, нужно бэкапить либо всю систему сразу, либо образ диска. Если у вас небольшой веб сервер, то скорее всего на нем только один раздел. На этом же разделе хранится кэш, который использует webdav для передачи файлов. Без кэша он работать не умеет.
Думаю вы уже поняли, в чем проблема сделать полный backup сервера с помощью Veeam Agent for Linux на Яндекс.Диск по webdav. Вы не сможете добавить в исключения папку с кэшом от webdav. В итоге, во время бэкапа с помощью veeam будет расти папка с кэшом webdav, которая, в свою очередь, будет бэкапиться. В итоге, свободное место на диске закончится, бэкап прервется.
Я подробно описал ситуацию с Яндекс.Диском, потому что пространство на нем не дорого стоит. Я часто его использую в повседневной жизни, настраиваю бэкапы, храню данные и т.д. В общем, мне он нравится по ряду причин. Для того, чтобы бэкапить весь сервер целиком, вам придется найти место для архивных копий с доступом по smb или nfs. Таких предложений не очень много на рынке. Практически не из чего выбирать, я специально искал.
Остановился вот на этом варианте - KeyDisk. После оплаты, вам дают адрес сервера, логин и пароль. Вы можете сразу же подключаться по smb к хранилищу. Можно прям в windows через два обратных слеша зайти или подмонтировать хранилище к linux серверу.
Дальше я подробно на конкретном примере расскажу как все настроить и восстановить или перенести сервер целиком, если понадобится. Причем переносить буду вообще на другое железо. Но обо всем по порядку.
Установка Veeam Agent for Linux
Для установки Veeam Agent for Linux необходимо подключить репозиторий veeam под нужную вам систему. Это можно сделать либо руками, либо скачать файл с репозиторием в виде rpm или deb пакета. Сделать это можно на странице с описанием продукта.
Для того, чтобы получить доступ к разделу с загрузками, придется зарегистрироваться. Выбираете тип системы и скачиваете репу.
Чуть ниже рекомендую сразу же скачать Veeam Linux Recovery Media. Он нам понадобится, когда мы будем переносить сервер на другое железо или восстанавливать из бэкапа.
Копируем файл с репозиторием на сервер и устанавливаем его. На момент написания статьи, файл можно было скачать по прямой ссылке.
Обновляем репозитории и устанавливаем veeam.
Все, Veeam Agent for Linux установлен и готов к работе.
Настройка полного бэкапа сервера
Сделать бэкап с помощью Veeam Agent for Linux очень просто. Вариантов настроек не так много, можете сами все проверить и посмотреть. Я для примера рассмотрю вариант с созданием полного бэкапа всей системы и перенос ее на другое железо. Создаем задачу для резервного копирования сервера на наше хранилище по smb.
Нам сразу же предлагают указать файл с лицензией. Так как у нас лицензии нет, то отказываемся. Нас встречает главное окно программы.
Нажимаем C (configure) для настройки задания на backup. Задаем любое имя задания, затем указываем, что будем делать полный бэкап сервера.
В качестве приемника для архива системы, указываем Shared Folder.
Далее нужно ввести параметры доступа к хранилищу бэкапов. Я использую свои от системы KeyDisk.
В пункте Restore Points указывается глубина архива. Это число копий, которые будут храниться на сервере. Если делать бэкап каждый день и указать число 14, то будут храниться резервные копии системы за последние 14 дней. Если делать будете через день, то за 28 дней и т.д.
Можно создавать несколько заданий с различной глубиной архива. Например, каждый день с глубиной 7 копий, раз в неделю с глубиной 4, и раз в месяц с глубиной в 12. Таким образом у вас всегда будут последние 7 бэкапов системы на этой неделе. Потом по одному бэкапу в неделю за последний месяц и 12 бэкапов по месяцам в течении последнего года.
Если получите ошибку:
Установите пакет cifs. В CentOS вот так:
И так в Debian/Ubuntu:
Запускайте заново veeam и продолжайте. После настройки Destination, предлагается указать скрипты для выполнения перед и после бэкапа. Нам сейчас это не надо. Далее настраиваем расписание и запускаем задание на архивацию в конце настройки.
Запустилась архивация. Можно следить за ее прогрессом.
После завершения архивации системы, можно проверить содержимое сетевого хранилища, зайдя на него прямо из винды.
На этом настройку полного бэкапа сервера мы завершили. Резервная копия системы лежит в надежном месте. Попробуем теперь с нее восстановиться.
Перенос или восстановление linux сервера
Представим теперь ситуацию, что наш веб, или какой-нибудь другой сервер умер, и нам надо восстановить систему в другом месте. Выполним полное восстановление всего сервера с помощью созданной ранее резервной копии. Для этого нам понадобится Veeam Linux Recovery Media, который мы скачали ранее.
Для восстановления системы нужно соблюсти два обязательных условия:
- Готовим новый сервер с диском, который должен быть не меньше диска исходного сервера. Это обязательное условие, иначе восстановление системы даже не начнется. Veeam скажет, что размер диска недостаточный и не предложит больше никаких вариантов восстановления.
- Оперативной памяти для системы должно быть не меньше 1024 Мб. Если меньше, то загрузка с диска не будет выполнена. Система скажет, что она не может развернуть корневой раздел.
Загружаемся с диска. В разделе Configure network убеждаемся, что сеть настроена, получен ip адрес, который имеет доступ к интернету. Далее выбираем Restore volumes -> Add shared folder. Заполняем параметры доступа к хранилищу архивов.
Выбираем там директорию с нашим архивом системы, которую будем восстанавливать. Далее будет показан список задач в левом столбце и список резервных копий в правом.
В моем случае там только одна копия. Выбираю ее. Дальше мы видим слева список дисков нашего сервера, справа диски резервной копии.
У меня слева чистый диск, справа тоже один диск, на который установлен загрузчик и есть один раздел с корнем системы. Выбираем справа наш диск (не раздел с корнем. ) и жмем Restore whole disk to.
В качестве приемника выбираем пустой диск на новом сервере.
Нажимаем S ( Start restore ). Визард покажет список действий, которые будут выполнены и попросит их подтвердить, нажатием на Enter.
Делаем это и наблюдаем за процессом восстановления сервера centos из бэкапа.
Дожидаемся окончания переноса сервера, выбираем перезагрузку и извлекаем загрузочный CD. Грузимся с жесткого диска.
Дальше может быть много различных вариантов. Если вы переносите сервер на тот же гипервизор, то проблем скорее всего не будет, и все заведется сразу. Если же гипервизор другой, то могут быть варианты, в зависимости от ситуации.
Перенос виртуальной машины с KVM на Hyper-V
В моем случае я переношу сервер с KVM на Hyper-V. После загрузки системы я получаю такую картину.
Сервер начинает бесконечно висеть в подобном состоянии с такими характерными ошибками:
Начинаю разбираться в чем может быть дело. Конечно, тут решение проблемы будет зависеть от конкретной ситуации. А успешность решения от квалификации сисадмина. Я уже немного повозился с подобными переносами и примерно представляю, в чем тут может быть проблема. Частично я эту тему затрагивал, когда делал перенос виртуальных машин с XenServer на Hyper-V. Но там была другая проблема, связанная с кастомным ядром от Xen.
В нашей ситуации с переносом виртуальной машины с KVM на Hyper-V проблема в другом. У нас поменялось имя диска. Нам нужно изменить это имя в fstab и в конфиге grub. До кучи я еще собрал заново initramfs, но не уверен на 100%, что в данном случае это нужно было делать. Я сделал на всякий случай сразу все за один заход.
Итак, загружаемся с установочного диска CentOS 7 и выбираем режим Rescue a CentOS system. Подробно об этом рассказывал в упомянутой ранее статье с переносом от xen. Выбираем первый режим запуска.
Дальше работаем в консоли. Смотрим, как называется наш диск.
У меня это sda, а на прошлом сервере он назывался vda. Нам нужно внести эти изменения в 2 файла:
Диск восстановления в самом начале мог сам смонтировать системный раздел в директорию/mnt/sysimage. Если он этого не сделает по какой-то причине, то сделайте это сами:
Теперь нам надо сделать chroot в систему, предварительно смонтировав туда информацию о текущей системе. Выполняем команды:
Мы загрузились в окружение нашего сервера. Тут можете использовать установленный у вас на сервере текстовый редактор. С его помощью изменяете имена дисков в файлах /etc/fstab и /boot/grub2/grub.cfg. Можете просто автозаменой поменять имена.
Теперь соберем новый initramfs. Идем в директорию /boot и смотрим там последнюю версию ядра.
В данном случае просто смотрим самые высокие цифры. Соберем новый initramfs в соответствии с версией ядра.
В завершении установим измененный загрузчик на наш диск:
Перезагружаем сервер. После этих изменений, у меня благополучно все загрузилось. Перенос виртуальной машины с KVM на Hyper-V выполнен полностью. Причем, у нас не было доступа к образу системы. Хотя подобная ошибка скорее всего все равно возникла бы, даже если бы мы конвертировали и переносили готовый образ.
Заключение
Изначально планировал написать небольшую заметку на тему использования Veeam для бэкапа сервера. Но в процессе получилось разобрать еще и перенос сервера с одного гипервизора на другой. Еще раз повторюсь, кому показалось это слишком сложным. Если вы будете бэкапить и восстанавливать сервер в рамках одного и того же гипервизора, то описанных выше проблем у вас не будет. Все пройдет гладко.
При переносе с железа на виртуальную машину или наоборот, тоже скорее всего возникнут какие-нибудь проблемы. Не существует софта или готового решения, которое бы позволило все это выполнить в автоматическом режиме. С проблемами загрузки придется разбираться по ходу дела. Но две основные проблемы я разобрал:
- Неподходящие версии ядер. После переноса нужно будет переустановить или обновить ядро.
- Разные имена дисков или меток разделов. Нужно будет их привести в соответствие с новым железом.
Это наиболее популярные проблемы. С другими мне не приходилось сталкиваться. Хотя не сказать, что мне часто приходилось переносить сервера, но некоторый опыт есть. Думаю, эта статья будем многим полезна, так как подобный перенос не очень раскрыт в статьях в интернете. По крайней мере мне не попадались хорошие гайды на эту тему. Разбираюсь обычно сам с помощью гугления по англоязычному сегменту.
Делитесь своим опытом и оставляйте замечания к статье или указывайте на ошибке в комментариях.
If you need to backup your system, there is no better way than making a backup with rsync.
Rsync (Remote Sync) is a popular and powerful tool used to copy and synchronize files and directories between remote or local Linux/Unix systems. With the help of rsync, we can easily copy/synchronize data between local and remote directories, across different drives and networks.
In this tutorial, I will show you how to make a backup with rsync using the Linux terminal. If you prefer graphical programs, you can use rsync with graphical interface too.
Video Tutorial
Making the backup with rsync
To make this tutorial, I will use Arch Linux in a virtual machine built with VirtualBox. To simulate an external hard drive, I will connect a USB flash drive where the backup will be stored and then restored. I recommend you do the same to test your backup. This will give you the confidence to know that your backup works because an untested backup is not a backup.
For this case we will use this entire command:
To make a backup with rsync, we usually use the command line. I know that not everyone is confident with the command line tools, but you will realize that the process is not that complicated and you can also back up your system using the command line.
We now proceed to explain what this command means:
sudo - to execute the command as a superuser. Mandatory use.
rsync - is the program itself to use.
-a - archive mode.
-A - preserve Access Control List.
-X - preserve extended attributes.
Basically, these three options mean to preserve all the attributes of your files. Owner attributes or permissions will not be modified during the backup process.
-v - It will show the progress of the backup.
--delete - this option allows you to make an incremental backup. That means, if it is not your first backup, it will backup only the difference between your source and the destination. So, it will backup only new files and modified files and it will also delete all the files in the backup which were deleted on your system. Be careful with this option.
--dry-run - This option simulates the backup. Useful to test its execution.
--exclude - Excludes folders and files from backup. I typed exclude as a separate option for every directory. You can also use it this way --exclude= . But make sure you change your working directory to root ( cd / ) before you run rsync, otherwise the joint exclude option may not work.
The excluded folders depend directly on each of us, however, the /dev/, /proc/, /proc/ /sys/ /tmp/ /run/ /mnt/ and /media folders are not important to backup because rsyn will not copy their content. /mnt/ it is vital to exclude them if we connect a USB memory.
/ - What we want to back up.
/run/media/alu/ALU - This is where you what to backup. I recommend to enrypt the destination, to make your data safe.
We press enter, the command will execute in a simulation mode (because of the --dry-run option) This way we test it to make sure everything is okay. When you’re sure that everything is performed as you want, you remove --dry-run from the command and run it again.
Note: It is recommended that the backup drive has a Linux compatible file system as ext4.
Restore the backup with rsync
To restore the backup we have made, we are going to boot from a live ISO. Since we are working with Arch Linux, then the iso image must be from Arch Linux. Next, we must mount our USB flash drive.
Once logged in from the live image, we must create two folders, one for the system on the hard disk and the other where the backup created will be mounted:
Next, we need to check the names of our devices:
Then, we must mount the file system and the backup on the USB flash device:
Finally, we proceed to perform the restoration of our backup. For this we run:
By running this command, we restore the backup of our system.
Conclusion
Rsync is a powerful tool that can be used from the command line, with multiple options that adapt to any need. You can of course use backup programs with graphical interface. There are also some really good non-open sources graphical backup programs.
Have you already done your backup? Let me know about your experience with rsync.
Создайте резервную копию с помощью rsync Если вам нужно сделать резервную копию вашей системы, нет лучшего способа, чем сделать резервную копию с помощью rsync.
Rsync (удаленная синхронизация) - популярный и мощный инструмент, используемый для копирования и синхронизации файлов и каталогов между удаленными или локальными системами Linux/Unix. С помощью rsync мы можем легко копировать/синхронизировать данные между локальными и удаленными каталогами, на разных дисках и в разных сетях.
В этом руководстве я покажу вам, как сделать резервную копию с помощью rsync, используя терминал Linux. Если вы предпочитаете графические программы, вы также можете использовать rsync с графическим интерфейсом.
Создание резервной копии с помощью rsync
Для создания этого руководства я буду использовать Arch Linux на виртуальной машине, созданной с помощью VirtualBox. Чтобы имитировать внешний жесткий диск, я подключу USB-флешку, где будет храниться резервная копия, а затем восстанавливаться. Я рекомендую вам сделать то же самое, чтобы проверить свою резервную копию. Это придаст вам уверенности в том, что ваша резервная копия работает, потому что непроверенная резервная копия не является резервной.
В этом случае мы будем использовать всю эту команду:
sudo rsync -aAXv --delete --dry-run --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/tmp/* --exclude=/run/* --exclude=/mnt/* --exclude=/media/* --exclude="swapfile" --exclude="lost+found" --exclude=".cache" --exclude="Downloads" --exclude=".VirtualBoxVMs"--exclude=".ecryptfs" / /run/media/alu/ALU/
Чтобы сделать резервную копию с помощью rsync, мы обычно используем командную строку. Я знаю, что не все уверены в инструментах командной строки, но вы поймете, что процесс не такой сложный, и вы также можете создать резервную копию своей системы с помощью командной строки.
Теперь мы переходим к объяснению, что означает эта команда:
sudo - выполнить команду от имени суперпользователя. Обязательное использование.
rsync - это сама программа, которую нужно использовать.
-a - режим архива.
-A - сохранить список контроля доступа.
-X - сохранить расширенные атрибуты.
По сути, эти три параметра означают сохранение всех атрибутов ваших файлов. Атрибуты или права владельца не будут изменены в процессе резервного копирования.
-v - покажет ход резервного копирования.
--delete - эта опция позволяет сделать инкрементную резервную копию. Это означает, что если это не ваша первая резервная копия, она сохранит только разницу между вашим источником и местом назначения. Таким образом, он будет создавать резервные копии только новых файлов и измененных файлов, а также удаляет все файлы в резервной копии, которые были удалены в вашей системе. Будьте осторожны с этой опцией.
--dry-run - этот параметр имитирует резервное копирование. Полезно для проверки его выполнения.
--exclude - Исключает папки и файлы из резервной копии. Я ввел exclude как отдельный параметр для каждого каталога. Вы также можете использовать его таким образом --exclude= . Но перед запуском rsync убедитесь, что вы изменили рабочий каталог на root (cd/), иначе опция совместного исключения может не работать.
Исключенные папки напрямую зависят от каждого из нас, однако папки /dev/, /proc/, /proc/ /sys/ /tmp/ /run/ /mnt/ и /media не важны для резервного копирования, потому что rsyn не будет копировать их содержание./mnt/жизненно важно исключить их, если мы подключаем USB-накопитель.
/ - То, что мы хотим сохранить.
/run/media/alu/ALU - это то, что нужно для резервного копирования. Я рекомендую зашифровать место назначения, чтобы ваши данные были в безопасности.
Нажимаем Enter, команда будет выполняться в режиме симуляции (из-за опции --dry-run ). Таким образом мы тестируем ее, чтобы убедиться, что все в порядке. Если вы уверены, что все выполняется так, как вы хотите, вы удаляете --dry-run из команды и запускаете ее снова.
Примечание. Рекомендуется, чтобы на резервном диске была файловая система, совместимая с Linux, как ext4.
Читайте также: