XFS, конечно же. По бенчмаркам оно с большими файлами себя ведёт лучше других. У меня уже 4 года на бэкапе единственный XFS на 21Тб + бакула - проблем с ними не было.

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

raw

А какой там скрип? Она вроде даже онлайн расширяться умеет. Я в свое время массив немного поменьше расширял, XFS выросла на ура, проблем не было. Ну и проектировать бэкап надо с запасом, чтобы не пришлось расширять :) Проще подключить еще одну дисковую полку и сделать там вторую ФС.

а гроувится с большим скрипом

4.2

ext4, ибо не храню терабайты ненужностей. Чисто свои фотки и по мелочи - почти 1000 файлов всего.

xfs

ext3, ext4 можно настроить на хранение больших файлов

mkfs.ext3 -m 0 -i 1048576 /dev/sda4

backup'ы - штука специфичная, они огромного размера, прямо внутри у них хочется чего-нибудь поискать

мне интересно: зачем вы делает бекапы большого размера, если всё равно храните их в ФС, и вам хочется что-то там поискать? ССЗБ на марше?

ЗЫЖ по сабжу: ext4 у себя + облака.

Снепшоты на zfs, которые затем и бэкапятся.

Universal Disk Format

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

XFS однозначно.

ext4, ибо железо «сервера» с бэкапами другие не тянет.

шифрованные бэкапы в duplicity и удалённые хранилища (SFTP, FTP, WebDAV, и другие)

На локальных везде — ext4, зарекомендовавшая себя как самая простая и беспроблемная ФС с хорошей производительностю в бытовых условиях (нет у меня миллиардов файлов по несколько Кб и громадных размером в терабайты)

но тем не менее уже почти нигде на ленту не записывающаяся в силу объективных причин как то: 21-й век на дворе

неудачная шутка, попробуйте ещё. я уже лет 10 назад это слышал, а корованыбэкапы всё равно в основном на ленту идут. и на месте не стоят - тыц

а можно и zfs с дедупом и компрессией, коли лента «мертва».

NTFS

Вчера коллега для домашнего СДХ выбирал фс. Остановились на ext2.

Остановились на ext2.

а чего не FAT?

коллега для домашнего СДХ выбирал фс

IMHO, для домашней СХД нужно выбирать не ФС, а iSCSI. При этом target может в СХД храниться на ZFS, а клиент пусть форматирует во что хочет.

У меня уже 4 года на бэкапе единственный XFS

Бэкап бэкапа делаешь?

И бэкап бэкапа бэкапа - тоже :)

А что ты предлагаешь? Как делать бекапы, если периодически в них надо что-то искать?

Как делать бекапы, если периодически в них надо что-то искать?

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

я долго мучал ехт2, но потом всё равно ушёл на ехт4, а почему вы именно на ехт2 решили остановиться? можно аргументы?

это не бекапы. Во всяком случае — не только бекапы.

Ок. Бекапы/Архивы.

если тебе мало возможностей cp, то используй DVCS

На десятках терабайтов данных? Ну-ну.

Нам нужна была большая скорость. А журналирование заметно снижает её. К сожалению точных цифр не вспомню, но вы можете в интернетах поискать.

какие ФС для бэкапов используете

JFS

и почему?

по приколу

Ок. Бекапы/Архивы.

зачем нужны архивы? Не, ну правда?

если тебе мало возможностей cp, то используй DVCS

На десятках терабайтов данных? Ну-ну.

какая разница сколько данных? Да и что у тебя за терабайты-то? Порнушка с интернетиков? Зачем там что-то круче cp? Ну ладно, пусть будет scp, дабы за попку не схватили.

Нам нужна была большая скорость. А журналирование заметно снижает её.

снижает. Ну купили-бы маленький быстрый носитель для журнала.

Ну и опускать надёжность ниже плинтуса для хранилища бекапов — просто глупо ИМХО.

хм, я за то же бился, в итоге ext4 с discard выбрал... и заодно fsck горадзо быстрее выполняется (даже 160ГБ раздел может долго проверяться на ext2)

зачем нужны архивы? Не, ну правда?

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

Зачем там что-то круче cp?

Для понтов же. Вобще, я этот пост написал в контексте ФС/носителей для бекапов, а не инструментов. В принципе, и scp неплохой вариант да.

rsync + ext4

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

именно АРХИВОМ?

для хранилища бекапов

Вчера коллега для домашнего СДХ выбирал фс

Я тоже думал над отключением журналирования на ext4, но остался на ext2.

именно АРХИВОМ?

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

только XFS, причём не только для бэкапа.

Дело хозяйское, спасибо за ответ :)

именно АРХИВОМ?

Именно. Но под АРХИВОМ ты же не tar подразумеваешь, да?

Да не за что =)

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

ну для лент из начала 90х годов — могу только согласится.

Именно. Но под АРХИВОМ ты же не tar подразумеваешь, да?

есть ещё что-то?

ну для лент из начала 90х годов

ленты будут рулить бэкапами ещё долго. а архив это не только tar, открой для себя hitachi content platform, netapp data archive и тд

что ты этим решил доказать?

Под архивом я подразумевал «архивное хранение». Безотносительно инструмента.

а я — один файл.

Что до инструментов, то на ЛОРе каждый день я слышу про то, что я ламо, и «ничего не понимаю в терабайтных бекапах», но вот ЧТО в этих бекапах лежит, узнать мне так и не довелось. А именно от этого как раз и зависит выбор инструмента. Как не странно.

что ты этим решил доказать?

доказать? эк тебя опять понесло, даже не знаю что ответить.

а я — один файл.

и кто тебе виноват ?

Что до инструментов, то на ЛОРе каждый день я слышу про то, что я ламо, и «ничего не понимаю в терабайтных бекапах»,

Не понимаешь, факт.

но вот ЧТО в этих бекапах лежит, узнать мне так и не довелось.

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

Ну а если тебе кажется что задач генерирующих большие объемы данных в реальности не существует, то ССЗБ.

man Биллинг man АСУТП man http://home.web.cern.ch/about/updates/2013/02/cern-data-centre-passes-100-pet...