Кодировка файлов в dump/restore

1. dump для целей бекапа русских файлов не годится вообще и нужно использовать что-то более другое

dump вообще не годится для бекапов в этом тысячелетии. Нормальные люди используют что-то более новое, tar например. Кстати, когда юзали dump, гугла ещё не было.

PS: попробуй гуглить «dump» (с кавычками вместе)

Внезапно verbose во внутренней консоле ресторе дало эффект показа русских файлов. Не ожидал.

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

Ага, особенно хорошо у tar с произвольным доступом, лол.

Внезапно verbose во внутренней консоле ресторе дало эффект показа русских файлов. Не ожидал.

на самом деле, dump вообще не в курсе про русские буквы. Для него это самые обычные байты, потому с русскими именами dump/restory работает нормально. Проблема только в их отображении твоим терминалом.

Ага, особенно хорошо у tar с произвольным доступом, лол.

всё нормально у tar'а с произвольным доступом. Ты просто не умеешь их готовить.

всё нормально у tar'а с произвольным доступом.

Серьёзно? Ну покажите мне, где там индекс находится. Только не надо костылей с внешним индексом, это, право, смешно.

Проблема только в их отображении твоим терминалом.

Это проблема в restore. У меня тоже воспроизводится. В xfsrestore любые символы отображаются без дополнительных телодвижений.

Серьёзно? Ну покажите мне, где там индекс находится. Только не надо костылей с внешним индексом, это, право, смешно.

т.е. вы не понимаете разницы в отсутствии внутреннего индекса и в отсутствие произвольного доступа?

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

т.е. вы не понимаете разницы в отсутствии внутреннего индекса и в отсутствие произвольного доступа?

А кто говорил об отсутствии? :)

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

Ну, это когда как. Наверно, вы просто не пробовали выдернуть единичный файл откуда-нибудь из конца ленточного архива размером хотя бы 100-200 Гб. Для этого как раз существуют dump/restore.

Ну, это когда как. Наверно, вы просто не пробовали выдернуть единичный файл откуда-нибудь из конца ленточного архива размером хотя бы 100-200 Гб. Для этого как раз существуют dump/restore.

что мешает юзать многотомные архивы? файл в 100..200Гб это само по себе уже не очень радует...

что мешает юзать многотомные архивы?

Без предварительной сортировки довольно сложно будет угадать, в каком их томов находится нужный файл. Кроме того, насколько я знаю, есть только одна реализация tar, поддерживающая многотомные архивы.

файл в 100..200Гб это само по себе уже не очень радует...

Это нормально для бэкапа целой ФС. tar здесь точно неуместен.

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

дык отсортируй. Что мешает-то?

Кроме того, насколько я знаю, есть только одна реализация tar, поддерживающая многотомные архивы.

тебе первая буковка в названии этого форума ни о чём не говорит? или ты с маздая сюда случайно заполз и уже случайно звезду надолбил? Намекаю: gnu tar умеет многотомные. Про другие реализации - не в курсе. Спроси на винфаке или там на гейфаке.

Это нормально для бэкапа целой ФС. tar здесь точно неуместен.

почему неуместен-то? вот мужики-то и не знали...

Что мешает-то?

Здравый смысл.

Про другие реализации - не в курсе.

Самое время освоить матчасть. Стандартная утилита для работы с tar и cpio, впервые появившаяся в IEEE Std 1003.1-2001 называется pax и не поддерживает многотомные архивы. Отсебятина GNU Tar (вроде кривой реализации инкрементальных архивов) может идти лесом.

почему неуместен-то?

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

Здравый смысл.

когда хочется сортировать не сортировать? Типа силу воли развивать что-ли?

Самое время освоить матчасть. Стандартная утилита для работы с tar и cpio, впервые появившаяся в IEEE Std 1003.1-2001 называется pax

самое время попинать унылое говно сдохшего мамонта.

Отсебятина GNU Tar (вроде кривой реализации инкрементальных архивов) может идти лесом.

инкрементальные архивы там есть и новые и старые. Не пугай новичков. Кстати старые мне не нравятся. А tar, если ты не знал, уже не первый десяток лет стандарт дефакто. Как среди хомячков WinRAR.

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

у нас 2013й на дворе, и уже нет никакой необходимости упаковывать 100500 файлов в один архив. Нынешние ФС умеют и больше файлов держать в одном каталоге. Костыль-архив в данном случае просто не нужен.

самое время попинать унылое говно сдохшего мамонта.

Я понимаю, что на стандарты дерзким линуксоидам плевать… Но в стандарте 2008 года всё то же самое. И в LSB (свежайшей версии, не экскременты мамонта!) это тоже есть.

инкрементальные архивы там есть и новые и старые.

И отличаются выдающейся ненужностью. Инкрементальный архив, не учитывающий удалённые на источнике файлы, в лучшем случае неудобен.

стандарт дефакто

Tar — да. GNU Tar — нет. Полагаться на его расширения за пределами любимого локалхоста, как минимум, несколько неосмотрительно.

Нынешние ФС умеют и больше файлов держать в одном каталоге.

Это хорошо, я в курсе :) Но речь, начиная с топика, шла об архивации для целей резервного копирования. Я вообще предпочитаю для личных нужд rsync без сношений с tar/dar/dump и прочими, но это не везде так.

плюсую адекватный ответ.

Я понимаю, что на стандарты дерзким линуксоидам плевать… Но в стандарте 2008 года всё то же самое. И в LSB (свежайшей версии, не экскременты мамонта!) это тоже есть.

стандарты - это _очень_ древнее говно мамонта. Их необходимо соблюдать, но это НЕ значит, что новые фишки не нужны. Нужны. Причём совместимые со старым стандартом, если это возможно.

И отличаются выдающейся ненужностью. Инкрементальный архив, не учитывающий удалённые на источнике файлы, в лучшем случае неудобен.

слушай, осиль наконец какую-нить VCS, это не задача архиватора.

Tar — да. GNU Tar — нет. Полагаться на его расширения за пределами любимого локалхоста, как минимум, несколько неосмотрительно.

ты сам сказал, что мы не в девяностых. BSD-хостов без gnu tar я давно уже не видел. Даже за пределами моих локалхостов.

Это хорошо, я в курсе :) Но речь, начиная с топика, шла об архивации для целей резервного копирования.

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

Я вообще предпочитаю для личных нужд rsync без сношений с tar/dar/dump и прочими, но это не везде так.

дык я тоже предпочитаю rsync. А где не так? Вот в слаке даже dump/restory нету... Что делать-то? А вот gnu tar & rsync таки есть...

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

ты про dump? Или всё-таки про tar(который кагбе TApe aRchiver)? :-D

какой-то неправильный у тебя гугл

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

ты про dump? Или всё-таки про tar(который кагбе TApe aRchiver)?

вообще.