forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Релиз GNU tar 1.30, opennews (?), 18-Дек-17, (0) [смотреть все]

Всю жизнь жду когда же наконец уже эту окаменелость отправят на свалку истории и, Онаним (?), 00:56 , 18-Дек-17, (1) –29 //

Не осилил -J , QuAzI (ok), 01:01 , 18-Дек-17, (2) +4
tar это не запакованный формат , Аноним (-), 01:03 , 18-Дек-17, (3) +1 //

Вообще-то он как раз формат упаковки архивирования, а не сжатия компрессии , angra (ok), 03:30 , 18-Дек-17, (9) +17 //

Да, но часто вы встречаете просто tar, а не tar gz файлы Для каких-то своих кас, Онаним (?), 04:42 , 18-Дек-17, (17)

Хотя даже на кассетах непонятно зачем оно нужно такое - почему бы перед записью , Онаним (?), 04:48 , 18-Дек-17, (18) –5

ты забегаешь вперед Этот нюанс как раз является одной из проблем tar, которые д, Greg KH (?), 06:19 , 18-Дек-17, (24)
Еще раз, tar - формат архивирования Не сжатия Нужно сжатие - жми отдельно Мож, Вася (??), 21:06 , 19-Дек-17, (111)

Это уже случилось бы давно, если бы существовал нормальный архиватор Но вместо , Greg KH (?), 06:27 , 18-Дек-17, (25) –1

Рад, что хоть кто-то понимает о чём я Чем не нравится 7zip Формат вроде достато, Онаним (?), 09:31 , 18-Дек-17, (27) –5

Можете начать прямо сейчас , Аноним (-), 10:19 , 18-Дек-17, (32)
его надо весь лопатить Изначально 7z был настолько инороден POSIX, GNU Linux и , Greg KH (?), 11:32 , 18-Дек-17, (39) +3

WinRAR к твоим услугам , VINRARUS (ok), 08:00 , 19-Дек-17, (94) –6

Тот же tar сверху никто не принимал Он сначала стал распространённым благода, Аноним (-), 13:38 , 18-Дек-17, (54) +2

bsdtar умеет через libarchive И есть ещё http www mirbsd org pax htm которы, Пользователь Debian (?), 17:53 , 18-Дек-17, (70) –1

Я про него и говорил Из pax 1 Усё , Аноним (-), 19:59 , 18-Дек-17, (78)

Как человек, не понаслышке знакомый с внутренностями 7z хотя все-таки понаслышк, Вася (??), 21:15 , 19-Дек-17, (112) +1

Ничего не заменило tar, потому что ерунда это, а не проблема На практике 99 юз, Crazy Alex (ok), 16:24 , 18-Дек-17, (64) +6

Да запросто, когда нужно перенести кучу jpg png avi, сжимать которые смысла нету, ALex_hha (ok), 19:28 , 19-Дек-17, (109)

я вам 7zip 18 лет назад написал, пользуйтесь, и правнукам передайте А tape arch, Pgor Iavlov (?), 01:08 , 18-Дек-17, (4) –3 //

Тише ты, чего расшумелся Ну не знают хомячки что архивация и сжатие это абсолют, DiabloPC (ok), 01:38 , 18-Дек-17, (5) +3 //

В 99 случаев это разделение не нужно Приведите мне хоть один пример, когда tar, Онаним (?), 04:32 , 18-Дек-17, (15) –3

Как минимум там, где мне это нужно, я могу выкинуть tar gz в пользу хоть tar l, имя (?), 04:48 , 18-Дек-17, (19) +6

7z a -t gzip bzip2 lzma2 xz и т п Не пробовал хотя понимаю, что чудом не понадо, Онаним (?), 05:34 , 18-Дек-17, (21) –1

Такие форматы есть, просто они не так часто бывают нужны tar чаще всего использ, Аноним (-), 14:41 , 18-Дек-17, (59)
Не работает ни с какими ключиками Точнее работает в том случае, когда пакуется , Аноним (-), 15:55 , 18-Дек-17, (62) +3
Понимаешь, у тебя чисто виндовый подход засунуть в одну утилиту все и вся Чтоб, Вася (??), 21:24 , 19-Дек-17, (113)

Вот пускай бы те, кто пишет на кассеты этим и пользовались Но нет, этим по дура, Онаним (?), 04:29 , 18-Дек-17, (14) –5 //

Выкинь на помойку свой RAR уже Его лет 10 как тот же 7-zip обскакал по скорости, Аномномномнимус (?), 10:51 , 18-Дек-17, (34) +1

RAR не тронь , VINRARUS (ok), 07:57 , 19-Дек-17, (93) –4

Да с чего бы Даже под форточкой перешёл на 7z , . (?), 02:53 , 20-Дек-17, (122)

WinRAR реализовал идею tar gz под винду в виде непрерывных архивов, токо не так , VINRARUS (ok), 01:14 , 21-Дек-17, (129) –2

умиление О, да Это несомненный плюс, прямо таки обдно из главных достоинств лю, Дим (?), 11:20 , 19-Дек-17, (99) +3
Вот не надо Не знаю как сейчас, но раньше он был гвоздями прибит к COM какая н, dq0s4y71 (ok), 15:43 , 19-Дек-17, (105)

С 7zip просто невозможно нормально работать в консоли В частности потому что в , Аноним (-), 13:41 , 18-Дек-17, (55) +3

Оу, а split-ом нарезать архив и гордо именовать это многотомным архивом ты тоже , Аноним (-), 09:06 , 18-Дек-17, (26) –1 //

ваши внуки уже не будут помнить, зачем вы пользовались split , Pgor Iavlov (?), 16:48 , 18-Дек-17, (67) –3

Да не - у них размер файла до гуглебайта всего то Так что придётся сплитить - , . (?), 02:45 , 20-Дек-17, (119)

Ругаются на ftp, теперь на tar а когда надо быстро прокинуть по сети миллионы м, Аноним (-), 04:24 , 18-Дек-17, (13) –1 //

Всегда когда не нужно сохранять права доступа и ссылки делаю это через 7z по SFT, Онаним (?), 04:38 , 18-Дек-17, (16) –4 //

Да знаю я 7z, но мне когда надо образ рабочей системы клонировать, то нужны прав, Аноним (-), 11:33 , 18-Дек-17, (40) +2

netcat tarНа исходной машине tar -czf - 124 nc целевой_ip portна целевой , anonymous (??), 12:33 , 18-Дек-17, (45) +1

То же самое хотел написать Наименее затратный вариант И совершенно непотребный, Аноним (-), 13:54 , 18-Дек-17, (57) +1

Это с единичным примером все хорошо, а у меня автоматизированное управление с ан, Аноним (-), 19:57 , 18-Дек-17, (77)

Ну и что в приведённом мной примере не автоматизировано Полностью неинтерактивн, Аноним (-), 20:13 , 18-Дек-17, (79)

Зачем городить какие-то костыли с поднятием FTP если он поднимается по запросу н, Аноним (-), 21:28 , 18-Дек-17, (84)

Где же просто Ты используешь дополнительный сервис как минимум FTP, если VPN у, Аноним (-), 13:29 , 19-Дек-17, (102)

я бы не был так категоричен, никто не мешает отключить компрессию и использовать, ALex_hha (ok), 19:37 , 19-Дек-17, (110) –1

мы мешаем, секьюрить наша всьо Поэтому мы отломали этот ваш вредный аркфор, сле, openssh (?), 17:54 , 20-Дек-17, (128)

так в этом и проблема, что у всех синдром утенка, и кроме tar ничего нет более-м, Greg KH (?), 05:56 , 18-Дек-17, (23) –1 //

Огласите пожалуйста минусы tar У cpio я знаю проблемы, у tar - нет , Аноним (-), 11:29 , 18-Дек-17, (38)

Самый критичный - отсутствие индекса для оптимального рандомного доступа к данны, Greg KH (?), 11:42 , 18-Дек-17, (41)

Вообще-то, это зависит от реализации pixz, например, умеет создавать индекс , Аноним (-), 12:42 , 18-Дек-17, (47)

squashfs тоже умеет Но это совсем другой формат, к тому же прибито к компрессор, Greg KH (?), 12:55 , 18-Дек-17, (49) –1

tar pixz создают совершенно обычный tar xz, у которого в конце индекс Распак, Аноним (-), 13:16 , 18-Дек-17, (51) +2

А, это точно, ведь tar-у хвост не нужен Согласен, юзабельно, вот такое можно ре, Greg KH (?), 13:37 , 18-Дек-17, (53) –3

См mksquashfs 1 , Аноним (-), 13:58 , 18-Дек-17, (58) +1

аноним, Но pixz это совсем другой формат, к тому же прибито к компрессору xz , Greg KH (?), 19:40 , 18-Дек-17, (76) –1

Рассматривать squashfs 124 btrfs 124 zfs в качестве архиватор упаковщик дл, PnDx (ok), 15:06 , 18-Дек-17, (61)

Это надо основательно yпороться, чтобы присовокупить btrfs и zfs А squashfs 8, Аноним (-), 16:02 , 18-Дек-17, (63)

Ну, тогда удачи поменять в архиве 3 ТБ вот тот файлик и потом отдать изменё, PnDx (ok), 17:06 , 18-Дек-17, (68) –2

Ну да, есть оговорки в плане области применения Там, где нужно менять файлы, на, Аноним (-), 18:00 , 18-Дек-17, (71)

Зависит от количества файлов, мы же про tar, не про tar gz Для распаковки одног, Аноним (-), 20:33 , 18-Дек-17, (80)

rsync , Аноним (-), 17:09 , 20-Дек-17, (127)

Я тоже жду такого в отношении местных Онанимов, бедный буратино (ok), 04:55 , 18-Дек-17, (20) +2
Есть резон, да Присоединяйтесь http duplicity nongnu org new_format html, Greg KH (?), 05:38 , 18-Дек-17, (22) –2 //

Да, на duplicity стоит обратить внимание И про замену tar хорошие мысли, но, ког, Аноним (-), 11:09 , 18-Дек-17, (36) –2 //

Согласен Всё го но, пусть уже делают мене хорошоу, бездельники XXX , Andrey Mitrofanov (?), 13:35 , 18-Дек-17, (52) +2

хе-хе, видать ты еще не вкурсе, что есть еще и долго еще будет cpio я бы не д, Sfinx (ok), 10:46 , 18-Дек-17, (33) +5
И это реально такая большая проблемма чтобы ждать ее решения всю жизнь Чувак, н, Дим (?), 11:26 , 19-Дек-17, (100) –2

Ого Оно еще развивается, я думал, что утилиту уже отшлифовали до идеала Круто , Борщдрайвен бигдата (?), 02:57 , 18-Дек-17, (7) //

Одно время отсылал авторам пару мелких патчей, для чего ковырялся в исходниках , Аноним (-), 03:37 , 18-Дек-17, (10) +4 //

Реальный мир вообще не склонен укладываться в любые модели системы архитектуры , angra (ok), 03:46 , 18-Дек-17, (11) –2
Интересно было бы переписать тар на лиспе или схеме и посмотреть, что получитс, Vjatcheslav (?), 20:53 , 18-Дек-17, (82) //

На чём угодно гораздо удобнее и быстрее написать прототип, чем составлять специф, Аноним (-), 23:46 , 18-Дек-17, (86) +1
Уже https github com froydnj archive blob master tar lisp, Вася (??), 21:44 , 19-Дек-17, (114)

Mc все так же виснет на 12 минут при нажатии F3 по нему , Аноним (-), 03:09 , 18-Дек-17, (8) –5 //

Может ты zip имел в виду, дурашка , Аноним (-), 12:23 , 18-Дек-17, (44) +1

частенько использую tar для того чтобы сохранить большое число маленьких файлов , eganru (?), 09:58 , 18-Дек-17, (30) –3 //

данет see 41 , Greg KH (?), 11:44 , 18-Дек-17, (42) –2 //

Если У Вас 100GB в архивах, то Вам явно необходимо что-то менять в консерватории, Аноним (-), 12:04 , 18-Дек-17, (43) //

А это не нашей консерватории архив Понимаешь в чем дело, когда все вокруг следу, Greg KH (?), 12:39 , 18-Дек-17, (46) –4

Кстати, для gz - не больше 2GB Там внизу man gzip написано, что оно не работа, Greg KH (?), 12:46 , 18-Дек-17, (48) –6

Во-первых, 4Г Во-вторых, работает, только размер сжатого файла неправильно отоб, Аноним (-), 14:55 , 18-Дек-17, (60) +5

О, замечательно, заглянули в мансамому то не смешно Ты либо сознательно прикиды, Greg KH (?), 19:22 , 18-Дек-17, (73) –2

Я и не предлагаю таким образом проверять размер файла, я таким образом просто по, Аноним (-), 21:08 , 18-Дек-17, (83) +1

А ты видимо тред не читал Здесь всё есть, грепай по 100 Когда припекает, а так, Greg KH (?), 03:39 , 19-Дек-17, (90) –2

Это не наколенные поделки, просто они отчасти морально устарели и не всегда соот, Аноним (-), 13:07 , 19-Дек-17, (101) +1

squashfs имеет встроеную дедупликацию , VINRARUS (ok), 18:02 , 19-Дек-17, (108) –1

Если ее не дополнили, т е дедупликация на уровне файлов, то это не то В дедуп, Аноним84701 (ok), 22:11 , 19-Дек-17, (115)
Это ж какие размеры используемой оперативки должны быть при упаковке В блочной , VINRARUS (ok), 00:34 , 20-Дек-17, (117) –1
Там в основном оперативка под индексы уходит, а данные полностью в ОЗУ держать н, Аноним84701 (ok), 01:57 , 20-Дек-17, (118) +1
Ну так ясно Другими словами должен совпадать 1 кб непрерывных данных Ну да, 16 , VINRARUS (ok), 02:59 , 20-Дек-17, (123) –1

Так и что плохого в архивах по паре сотен гб где-то в s3, например , Борщдрайвен бигдата (?), 13:52 , 18-Дек-17, (56) –1

Да ничего, но товарищ там зачем-то листинги хочет и частичную распаковку Не пом, Crazy Alex (ok), 16:33 , 18-Дек-17, (66)

хватит лицемерить Неужели, желание списка файлов в архиве - это такой жупел, чт, Greg KH (?), 19:26 , 18-Дек-17, (74) –1
Так ведь tar не особо для этого Собрать файлы в один, положить на ленту и забыт, Борщдрайвен бигдата (?), 20:36 , 18-Дек-17, (81) +1

Отлично не держать слишком больших архивов, потому что с ними неудобно работать, Анонимм (??), 16:32 , 18-Дек-17, (65) +1

Влет это как Смонтировать через losetup, и скопировать необходимый файл Ну, , Аноним (-), 17:45 , 18-Дек-17, (69) –1

дамп в смысле высокоуровневого , сделанного через утилиту dump Влет, это подклю, Анонимм (??), 19:16 , 18-Дек-17, (72) +2
Вы реально настолько некомпетентны, не понимаете, почему dump-архив позволяет вы, Greg KH (?), 19:30 , 18-Дек-17, (75) –1

Спасибо, за публичную порку Так давно это было, что аж успело забыться Еще ра, Аноним (-), 09:35 , 19-Дек-17, (96) +1

Спасибо за адекват, анонимусМне вообще странно, почему dump не особо популярен в, Greg KH (?), 11:19 , 19-Дек-17, (98) –2

Мне вообще кажется, что достаточно важно в этом вопросе это то, что система позв, Аноним (-), 13:42 , 19-Дек-17, (103)

У меня нет цели какого-либо детального анализа или желания вдруг что-то там по о, eganru (?), 23:13 , 18-Дек-17, (85)

Вендузоиды бомбят Хорошо , Аноним (-), 12:58 , 18-Дек-17, (50) +4
какой консольный компрессор под уникс посоветуете главное требование максимальн, Аноним (-), 00:24 , 19-Дек-17, (87) –2 //

xz, Глупышь (?), 02:11 , 19-Дек-17, (88) +2
Какие ещё требования Какой способ применения, что потом будет с файлами Как бу, Борщдрайвен бигдата (?), 02:44 , 19-Дек-17, (89)
lzip конечно же и его параллельная реализация plzip, Greg KH (?), 03:42 , 19-Дек-17, (91) //

Есть какие-то объективные причины использовать его, а не xz, ставший уже стандар, Аноним (-), 15:23 , 19-Дек-17, (104) –1 //

http www nongnu org lzip xz_inadequate htmlКраткая выжимка Key findings includ, Анонимм (??), 16:05 , 19-Дек-17, (106)

Почитал Отчасти выглядит разумно, отчасти 8212 явные придирки, отчасти 821, Аноним (-), 17:45 , 19-Дек-17, (107) –1

спасибо почитаю подробнее про алгоритмы файлы обычные не системные из хоум дир, аноним_оп (?), 05:53 , 19-Дек-17, (92) //

предлагаю использовать squashfs см man mksquashfs , компрессию ему можно указат, Greg KH (?), 09:06 , 19-Дек-17, (95) //

squashfs крут тем шо его можна просто смонтировать в любую папку и работать даль, VINRARUS (ok), 10:53 , 19-Дек-17, (97) –3

Подскажи как на WindowsXP Solaris AIX iOS11 смонтировать сквошу , pavlinux (ok), 02:46 , 20-Дек-17, (120) +2

Наш, Советский матрос - умеет задать правильный вопрос С , . (?), 03:55 , 20-Дек-17, (125) +1
Я на винде открывал через 7zip В теории возможно монтирование как обычный iso с, VINRARUS (ok), 04:15 , 20-Дек-17, (126) –3

А я откуда знаю, зачем вы сквошем пытаетесь заменить всея платформенный tar ta, pavlinux (ok), 03:01 , 21-Дек-17, (130) +1

Сообщения [Сортировка по времени | RSS]

43. "Релиз GNU tar 1.30" +/–

Сообщение от Аноним (-), 18-Дек-17, 12:04

>> tar быстро и без фокусов упаковывает их в контейнер
> да
>> с которым потом удобно работать
> нет (see #41 )
Если У Вас 100GB в архивах, то Вам явно необходимо что-то менять в консерватории.
И Вы там упоминали про duplicity, да, но наверное это тоже для Вас не вариант. Может как нибудь структурировать данные. Это конечно не уже не задачи архиваторов и упаковщиков.
И когда нибудь наверняка, должен будет появится довольно таки легковесный комбайн, который объединит все необходимое Вам в один флакон (да еще и в необходимой пропорции ;)

Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз GNU tar 1.30" –4 +/–

Сообщение от Greg KH (?), 18-Дек-17, 12:39

> Если У Вас 100GB в архивах, то Вам явно необходимо что-то менять в консерватории.
А это не нашей консерватории архив. Понимаешь в чем дело, когда все вокруг следуют советам из детской книжки "Линукс для чайников" писать всегда "tar czf" незадумываясь, то потом приходится иметь дело с такими вот 100GB tar.gz. Ну а что, "на форуме посоветовали", "в книжке написали", "в модном faq указали".
Вот я поставил минус #30, что бы дурными советами не разбрасывался товарищ.
Авторам статей, факов, ответов на форумах пора прекратить везде пихать tar без явного указания на то, что данные не должны быть больше пары гигабайт. Иначе будет бо-бо тому, что будет эти данные читать. И в man добавить стыдную инфу: не больше 5GB! Вот в этом мой пойнт.

Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз GNU tar 1.30" –6 +/–

Сообщение от Greg KH (?), 18-Дек-17, 12:46

> не больше 5GB!
Кстати, для gz - не больше 2GB. Там внизу `man gzip` написано, что оно не работает. Но кто ж читает ман на компрессор, когда сжимает в tar.gz.
Как все смеялись над fat32 с её невозможностью записывать туда образы DVD целиком! Но как-то все забыли, что классические линуксовые инструменты не работают должным образом с файлами >2GB.
STOP USING TAR! STOP USING GZ! Так победим!

Ответить | Правка | Наверх | Cообщить модератору

60. "Релиз GNU tar 1.30" +5 +/–

Сообщение от Аноним (-), 18-Дек-17, 14:55

>> не больше 5GB!
> Кстати, для gz - не больше 2GB. Там внизу `man gzip` написано,
> что оно не работает. Но кто ж читает ман на компрессор,
> когда сжимает в tar.gz.
Во-первых, 4Г. Во-вторых, работает, только размер сжатого файла неправильно отображается.
$ dd if=/dev/zero bs=1M count=5120 | gzip > file.gz
5120+0 записей получено
5120+0 записей отправлено
5368709120 байт (5,4 GB, 5,0 GiB) скопирован, 31,9478 s, 168 MB/s
$ gzip -l file.gz
         compressed        uncompressed  ratio uncompressed_name
            5210210          1073741824  99.5% file
$ zcat file.gz | wc -c
5368709120

> STOP USING TAR! STOP USING GZ!
Не дождётесь!

Ответить | Правка | Наверх | Cообщить модератору

73. "Релиз GNU tar 1.30" –2 +/–

Сообщение от Greg KH (?), 18-Дек-17, 19:22

> Во-первых, 4Г.
О, замечательно, заглянули в ман
> zcat file.gz | wc -c
самому то не смешно? Ты либо сознательно прикидываешься, либо абсолютно некомпетентен в IT.
Человек, считающий на полном серьезе, что O(N) - это допустимая сложность для алгоритма получения размера файла, не должен иметь права голоса на техническом форуме.

Ответить | Правка | Наверх | Cообщить модератору

83. "Релиз GNU tar 1.30" +1 +/–

Сообщение от Аноним (-), 18-Дек-17, 21:08

Я и не предлагаю таким образом проверять размер файла, я таким образом просто показал, что он сохранился полностью, хотя gzip -l и показывает ерунду. А вот когда мне в реальных условиях нужно было узнать размер сжатого файла — я с трудом припоминаю… Кажется примерно никогда. А тебе?

Ответить | Правка | Наверх | Cообщить модератору

90. "Релиз GNU tar 1.30" –2 +/–

Сообщение от Greg KH (?), 19-Дек-17, 03:39

>  А тебе?
А ты видимо тред не читал? Здесь всё есть, грепай по "100"
Когда припекает, а такой возможности нет, понимаешь, насколько наколенные поделки эти gzip и tar. Это совсем не уровень промышленной системы с почти полувековой традицией. Ты же не можешь заранее знать, чего наивный юзер загонит в архив. Вон, тут уже и 'tar | nc' советуют во все поля. И с ростом объемов юзеры будут сталкиваться с этим чаще и чаще, явная проблема. Нет, давайте будем молиться на этот tar и gzip, аки мощам.

Ответить | Правка | Наверх | Cообщить модератору

101. "Релиз GNU tar 1.30" +1 +/–

Сообщение от Аноним (-), 19-Дек-17, 13:07

Это не наколенные поделки, просто они отчасти морально устарели и не всегда соответствуют современным потребностям. Молиться не надо, но использовать, когда нужно обеспечить максимальную переносимость, стоит. В остальных случаях предпочитаю xz. От tar вижу смысл отказываться только тогда, когда действительно важен произвольный доступ (squashfs), нужна дедупликация (borg) или инкрементальные бекапы (dar). Однако не менее 90% юзкейсов — запаковать архив, передать его, распаковать целиком; тут tar годится не хуже любого другого архиватора.

Ответить | Правка | Наверх | Cообщить модератору

108. "Релиз GNU tar 1.30" –1 +/–

Сообщение от VINRARUS (ok), 19-Дек-17, 18:02

> От tar вижу смысл отказываться только тогда, когда действительно важен произвольный доступ (squashfs), нужна дедупликация (borg)
squashfs имеет встроеную дедупликацию.

Ответить | Правка | Наверх | Cообщить модератору

115. "Релиз GNU tar 1.30" +/–

Сообщение от Аноним84701 (ok), 19-Дек-17, 22:11

>> От tar вижу смысл отказываться только тогда, когда действительно важен произвольный доступ (squashfs), нужна дедупликация (borg)
> squashfs имеет встроеную дедупликацию.
Если ее не дополнили,  т.е. дедупликация на уровне файлов, то это не то.
В дедупе борга, аттики, zbackup (и вроде бы, лезть в сорцы лень) rsync и еще целой кучи утилит/клонов основная фишка в нахождении дублирующихся _кусков_ (а не просто блоков, как например в zfs или целых файлов, как в squashfs) данных вариативной длины.
Пример:
Файл А: 11 22 33 44 55
Файл Б: 11 22 33 44 55
Файл В: 11 22 33 44 56
Файл Г: 00  11 22 33 44
А и Б (дупликаты на уровне файлов) распознаются сквошем (хэш/пров. сумма файла)
B (часть данных различается) детектится блочными дедупликаторами, типа ZFS и сохраняется только отличающийся блок.
На Г ("сдвиг")  блочный дедупликатор обломится (если конечно "сдвиг" не равен кратному длины блока), а вот "кусочная" дедупликация сможет "отделить мух от котлет".
Естественно, все имеет свою цену - первый способ почти "бесплатен", т.к. при упаковке пров. суммы файлов все равно считаются, тем более, пакуются данные только один раз.
Поблочный дедупликатор считает при каждой записи, плюс ему нужны индексы (см. классическую интернациональную драму на форумах всего интернета "ZFS дедап жрет ОЗУ как не в себя!" - фряшники советуют исходить от 2 до 5ГБ ОЗУ на 1 ТБ файлов).
У дедапа с кусками различной длины есть недостатки предыдущих способов, плюс еще более подтормаживающий хэш (тут правда смотреть надо - питон он обычно скоростью не отличается, а zbackup-овых 40-60 МБ/s может вполне хватать). Но для инкрементальных бэкапов, хранения или передачи схожих данных по узкому каналу и прочего оно вполне себе очень даже ничего.
Ключевые слова chunks + rolling hash + rabin karp
Кроме педивикии, см. можно тут:
https://github.com/YADL/yadl/wiki/Rabin-Karp-for-Variable-Ch...
https://software.intel.com/en-us/articles/accelerate-data-de...

Ответить | Правка | Наверх | Cообщить модератору

117. "Релиз GNU tar 1.30" –1 +/–

Сообщение от VINRARUS (ok), 20-Дек-17, 00:34

>основная фишка в нахождении дублирующихся _кусков_ (а не просто блоков, как например в zfs или целых файлов, как в squashfs) данных вариативной длины.
Это ж какие размеры используемой оперативки должны быть при упаковке? В блочной дедупликации все просто и быстро с кс, а тут какое мин. количество байт участвует в дедупликации?

Ответить | Правка | Наверх | Cообщить модератору

118. "Релиз GNU tar 1.30" +1 +/–

Сообщение от Аноним84701 (ok), 20-Дек-17, 01:57

>>основная фишка в нахождении дублирующихся _кусков_ (а не просто блоков, как например в zfs или целых файлов, как в squashfs) данных вариативной длины.
> Это ж какие размеры используемой оперативки должны быть при упаковке? В блочной дедупликации все просто и быстро с кс, а тут какое мин. количество байт участвует в дедупликации?
Там в основном оперативка под индексы уходит, а данные полностью в ОЗУ держать нет нужды.
Eсли брать zbackup, то примерно 2МБ на ГБ данных в репе, автор
http://zbackup.org/ см. "Scalability"
говорит о  примерно 1ГБ ОЗУ на 1ТБ репы.

Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

123. "Релиз GNU tar 1.30" –1 +/–

Сообщение от VINRARUS (ok), 20-Дек-17, 02:59

>>>основная фишка в нахождении дублирующихся _кусков_ (а не просто блоков, как например в zfs или целых файлов, как в squashfs) данных вариативной длины.
>> Это ж какие размеры используемой оперативки должны быть при упаковке? В блочной дедупликации все просто и быстро с кс, а тут какое мин. количество байт участвует в дедупликации?
> Там в основном оперативка под индексы уходит, а данные полностью в ОЗУ
> держать нет нужды.
Ну так ясно.
> Eсли брать zbackup, то примерно 2МБ на ГБ данных в репе, автор
> http://zbackup.org/ см. "Scalability"
> говорит о  примерно 1ГБ ОЗУ на 1ТБ репы.
Другими словами должен совпадать 1 кб непрерывных данных.
Ну да, 16 кб на блок у btrfs это немного не то. :)

Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

56. "Релиз GNU tar 1.30" –1 +/–

Сообщение от Борщдрайвен бигдата (?), 18-Дек-17, 13:52

Так и что плохого в архивах по паре сотен гб где-то в s3, например?

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

66. "Релиз GNU tar 1.30" +/–

Сообщение от Crazy Alex (ok), 18-Дек-17, 16:33

Да ничего, но товарищ там зачем-то листинги хочет и частичную распаковку. Не помню, когда оно нужно было.

Ответить | Правка | Наверх | Cообщить модератору

74. "Релиз GNU tar 1.30" –1 +/–

Сообщение от Greg KH (?), 18-Дек-17, 19:26

> зачем-то листинги хочет
хватит лицемерить. Неужели, желание списка файлов в архиве - это такой жупел, что меня готовы уже вiндузятником объявить, лишь бы не признать, что tar (и gz) - убоги в качестве дефолтного решения, и используется только потому, что нет альтернативы.

> зачем-то листинги хочет
Ты себе макбук купил что ли? Симптомы больно похожи: ответ "ненужно" на вопрос о тривиальной фиче, которой нет в системе, и брызганье слюной после появления этой фичи в следующем релизе.

Ответить | Правка | Наверх | Cообщить модератору

81. "Релиз GNU tar 1.30" +1 +/–

Сообщение от Борщдрайвен бигдата (?), 18-Дек-17, 20:36

Так ведь tar не особо для этого. Собрать файлы в один, положить на ленту и забыть до Рагнарёка.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

65. "Релиз GNU tar 1.30" +1 +/–

Сообщение от Анонимм (??), 18-Дек-17, 16:32

>>> tar быстро и без фокусов упаковывает их в контейнер
>> да
>>> с которым потом удобно работать
>> нет (see #41 )
> Если У Вас 100GB в архивах, то Вам явно необходимо что-то менять в консерватории.
Отлично: не держать слишком больших архивов, потому что с ними неудобно работать и писать что все прекрасно работает и поэтому ничего менять не надо (а у кого работает не очень, тот конечно же ССЗБ). Напоминает яблочное "Вы просто свой айфон неправильно держите!"
Из того же dump архива, хотя он тоже изначально "кассетный", бэкапы отдельных файлов восстанавливаются только влет. Но tar был бы удобнее из-за отсутствия привязки к конкретной ФС.
Может просто стоит признать, что времена хардов на 100МБ безвозвратно ушли и современные требования к архивам немного изменились?

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

69. "Релиз GNU tar 1.30" –1 +/–

Сообщение от Аноним (-), 18-Дек-17, 17:45

> Из того же dump архива, хотя он тоже изначально "кассетный", бэкапы отдельных
> файлов восстанавливаются только влет. Но tar был бы удобнее из-за отсутствия
> привязки к конкретной ФС.
"Влет" это как? Смонтировать через losetup, и скопировать необходимый файл? Ну, тогда да!
Тогда пишите tar_fs с опциями gz, bz2, lzma, ... Правда скорость на мой взгляд будет, ну Вы поняли ;)
> Может просто стоит признать, что времена хардов на 100МБ безвозвратно ушли и
> современные требования к архивам немного изменились?
Да! Но это не значит, что tar необходимо выкинуть.

Ответить | Правка | Наверх | Cообщить модератору

72. "Релиз GNU tar 1.30" +2 +/–

Сообщение от Анонимм (??), 18-Дек-17, 19:16

> "Влет" это как? Смонтировать через losetup, и скопировать необходимый файл? Ну, тогда да!
дамп в смысле "высокоуровневого", сделанного через утилиту dump.
Влет, это подключить терабайтный хард с бэкапами к ноуту без USB3 и запустив restore -if на 100ГБом дамп-архиве, выбрать интерактивно файлы для восстановления и восстановить их. За пару минут, а не полчаса. Так же неплохо работает с пожатым дампом, если использовать блоковое сжатие.
> Да! Но это не значит, что tar необходимо выкинуть.
Вообще-то ветка ветка начинается с #30, где пишут о
> с которым потом удобно работать.
Или усомниться в безоговорочности удобства работы с tar в современных реалиях (и юзкейзах) уже сам по себе призыв к выкидыванию?

Ответить | Правка | Наверх | Cообщить модератору

75. "Релиз GNU tar 1.30" –1 +/–

Сообщение от Greg KH (?), 18-Дек-17, 19:30

> Ну, тогда да! Тогда пишите tar_fs с опциями gz, bz2, lzma, .
Вы реально настолько некомпетентны, не понимаете, почему dump-архив позволяет вытаскивать файлы быстро, а tar-архив - не позволяет? Ну так вы спросите сначала, может быть поймете, и не будете невежеством бравировать.

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

96. "Релиз GNU tar 1.30" +1 +/–

Сообщение от Аноним (-), 19-Дек-17, 09:35

>> Ну, тогда да! Тогда пишите tar_fs с опциями gz, bz2, lzma, .
> Вы реально настолько некомпетентны, не понимаете, почему dump-архив позволяет вытаскивать
> файлы быстро, а tar-архив - не позволяет? Ну так вы спросите
> сначала, может быть поймете, и не будете невежеством бравировать.
Спасибо, за публичную порку ;)
Так давно это было, что аж успело забыться. Еще раз посмотрел man dump и просторы Интернета. В очередной раз понравилось. К сожалению пока ручки не дошли. Все по старинке tar, rsync.
Но очень необходимо себя заставить изучить dump and duplicity, и сравнить (особенно в вопросе инкрементального backup-а).

Ответить | Правка | Наверх | Cообщить модератору

98. "Релиз GNU tar 1.30" –2 +/–

Сообщение от Greg KH (?), 19-Дек-17, 11:19

Спасибо за адекват, анонимус
> изучить dump and duplicity
Мне вообще странно, почему dump не особо популярен в linux, тогда как в bsd dump это мейнстрим.
А duplicity оставляет двоякое впечатление
Мне понравился borg backup из относительно свежего последного

Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз GNU tar 1.30" +/–

Сообщение от Аноним (-), 19-Дек-17, 13:42

> Спасибо за адекват, анонимус
>> изучить dump and duplicity
> Мне вообще странно, почему dump не особо популярен в linux, тогда как
> в bsd dump это мейнстрим.
> А duplicity оставляет двоякое впечатление
> Мне понравился borg backup из относительно свежего последного
Мне вообще кажется, что достаточно важно в этом вопросе это то, что система позволяет сразу после (или в течении) процесса обновления (создания) копии, сможет сделать unattended верификацию всей (или случайной части) сохраненной в резервной информации с оригиналом. И самое главное, в случае, если что то пошло не так, отправит сообщение (обязательно зашифрованное) на указанный в настройках системы адрес электронной почты (лучше на несколько ;)
В принципе все выше озвученное не так сложно реализовать путем скриптования (ну скажем на shell).
Просто должен найтись Человек, который с удовольствием, реализует начальный функционал в течении выходных! Позже, может кто то подключится и допилят.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	43. "Релиз GNU tar 1.30"	+/–
	Сообщение от Аноним (-), 18-Дек-17, 12:04
	>> tar быстро и без фокусов упаковывает их в контейнер > да >> с которым потом удобно работать > нет (see #41 ) Если У Вас 100GB в архивах, то Вам явно необходимо что-то менять в консерватории. И Вы там упоминали про duplicity, да, но наверное это тоже для Вас не вариант. Может как нибудь структурировать данные. Это конечно не уже не задачи архиваторов и упаковщиков. И когда нибудь наверняка, должен будет появится довольно таки легковесный комбайн, который объединит все необходимое Вам в один флакон (да еще и в необходимой пропорции ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Релиз GNU tar 1.30"	–4 +/–
	Сообщение от Greg KH (?), 18-Дек-17, 12:39
	> Если У Вас 100GB в архивах, то Вам явно необходимо что-то менять в консерватории. А это не нашей консерватории архив. Понимаешь в чем дело, когда все вокруг следуют советам из детской книжки "Линукс для чайников" писать всегда "tar czf" незадумываясь, то потом приходится иметь дело с такими вот 100GB tar.gz. Ну а что, "на форуме посоветовали", "в книжке написали", "в модном faq указали". Вот я поставил минус #30, что бы дурными советами не разбрасывался товарищ. Авторам статей, факов, ответов на форумах пора прекратить везде пихать tar без явного указания на то, что данные не должны быть больше пары гигабайт. Иначе будет бо-бо тому, что будет эти данные читать. И в man добавить стыдную инфу: не больше 5GB! Вот в этом мой пойнт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Релиз GNU tar 1.30"	–6 +/–
	Сообщение от Greg KH (?), 18-Дек-17, 12:46
	> не больше 5GB! Кстати, для gz - не больше 2GB. Там внизу `man gzip` написано, что оно не работает. Но кто ж читает ман на компрессор, когда сжимает в tar.gz. Как все смеялись над fat32 с её невозможностью записывать туда образы DVD целиком! Но как-то все забыли, что классические линуксовые инструменты не работают должным образом с файлами >2GB. STOP USING TAR! STOP USING GZ! Так победим!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Релиз GNU tar 1.30"	+5 +/–
	Сообщение от Аноним (-), 18-Дек-17, 14:55
	>> не больше 5GB! > Кстати, для gz - не больше 2GB. Там внизу `man gzip` написано, > что оно не работает. Но кто ж читает ман на компрессор, > когда сжимает в tar.gz. Во-первых, 4Г. Во-вторых, работает, только размер сжатого файла неправильно отображается. $ dd if=/dev/zero bs=1M count=5120 \| gzip > file.gz 5120+0 записей получено 5120+0 записей отправлено 5368709120 байт (5,4 GB, 5,0 GiB) скопирован, 31,9478 s, 168 MB/s $ gzip -l file.gz compressed uncompressed ratio uncompressed_name 5210210 1073741824 99.5% file $ zcat file.gz \| wc -c 5368709120 > STOP USING TAR! STOP USING GZ! Не дождётесь!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Релиз GNU tar 1.30"	–2 +/–
	Сообщение от Greg KH (?), 18-Дек-17, 19:22
	> Во-первых, 4Г. О, замечательно, заглянули в ман > zcat file.gz \| wc -c самому то не смешно? Ты либо сознательно прикидываешься, либо абсолютно некомпетентен в IT. Человек, считающий на полном серьезе, что O(N) - это допустимая сложность для алгоритма получения размера файла, не должен иметь права голоса на техническом форуме.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Релиз GNU tar 1.30"	+1 +/–
	Сообщение от Аноним (-), 18-Дек-17, 21:08
	Я и не предлагаю таким образом проверять размер файла, я таким образом просто показал, что он сохранился полностью, хотя gzip -l и показывает ерунду. А вот когда мне в реальных условиях нужно было узнать размер сжатого файла — я с трудом припоминаю… Кажется примерно никогда. А тебе?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Релиз GNU tar 1.30"	–2 +/–
	Сообщение от Greg KH (?), 19-Дек-17, 03:39
	> А тебе? А ты видимо тред не читал? Здесь всё есть, грепай по "100" Когда припекает, а такой возможности нет, понимаешь, насколько наколенные поделки эти gzip и tar. Это совсем не уровень промышленной системы с почти полувековой традицией. Ты же не можешь заранее знать, чего наивный юзер загонит в архив. Вон, тут уже и 'tar \| nc' советуют во все поля. И с ростом объемов юзеры будут сталкиваться с этим чаще и чаще, явная проблема. Нет, давайте будем молиться на этот tar и gzip, аки мощам.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	101. "Релиз GNU tar 1.30"	+1 +/–
	Сообщение от Аноним (-), 19-Дек-17, 13:07
	Это не наколенные поделки, просто они отчасти морально устарели и не всегда соответствуют современным потребностям. Молиться не надо, но использовать, когда нужно обеспечить максимальную переносимость, стоит. В остальных случаях предпочитаю xz. От tar вижу смысл отказываться только тогда, когда действительно важен произвольный доступ (squashfs), нужна дедупликация (borg) или инкрементальные бекапы (dar). Однако не менее 90% юзкейсов — запаковать архив, передать его, распаковать целиком; тут tar годится не хуже любого другого архиватора.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	108. "Релиз GNU tar 1.30"	–1 +/–
	Сообщение от VINRARUS (ok), 19-Дек-17, 18:02
	> От tar вижу смысл отказываться только тогда, когда действительно важен произвольный доступ (squashfs), нужна дедупликация (borg) squashfs имеет встроеную дедупликацию.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	115. "Релиз GNU tar 1.30"	+/–
	Сообщение от Аноним84701 (ok), 19-Дек-17, 22:11
	>> От tar вижу смысл отказываться только тогда, когда действительно важен произвольный доступ (squashfs), нужна дедупликация (borg) > squashfs имеет встроеную дедупликацию. Если ее не дополнили, т.е. дедупликация на уровне файлов, то это не то. В дедупе борга, аттики, zbackup (и вроде бы, лезть в сорцы лень) rsync и еще целой кучи утилит/клонов основная фишка в нахождении дублирующихся _кусков_ (а не просто блоков, как например в zfs или целых файлов, как в squashfs) данных вариативной длины. Пример: Файл А: 11 22 33 44 55 Файл Б: 11 22 33 44 55 Файл В: 11 22 33 44 56 Файл Г: 00 11 22 33 44 А и Б (дупликаты на уровне файлов) распознаются сквошем (хэш/пров. сумма файла) B (часть данных различается) детектится блочными дедупликаторами, типа ZFS и сохраняется только отличающийся блок. На Г ("сдвиг") блочный дедупликатор обломится (если конечно "сдвиг" не равен кратному длины блока), а вот "кусочная" дедупликация сможет "отделить мух от котлет". Естественно, все имеет свою цену - первый способ почти "бесплатен", т.к. при упаковке пров. суммы файлов все равно считаются, тем более, пакуются данные только один раз. Поблочный дедупликатор считает при каждой записи, плюс ему нужны индексы (см. классическую интернациональную драму на форумах всего интернета "ZFS дедап жрет ОЗУ как не в себя!" - фряшники советуют исходить от 2 до 5ГБ ОЗУ на 1 ТБ файлов). У дедапа с кусками различной длины есть недостатки предыдущих способов, плюс еще более подтормаживающий хэш (тут правда смотреть надо - питон он обычно скоростью не отличается, а zbackup-овых 40-60 МБ/s может вполне хватать). Но для инкрементальных бэкапов, хранения или передачи схожих данных по узкому каналу и прочего оно вполне себе очень даже ничего. Ключевые слова chunks + rolling hash + rabin karp Кроме педивикии, см. можно тут: https://github.com/YADL/yadl/wiki/Rabin-Karp-for-Variable-Ch... https://software.intel.com/en-us/articles/accelerate-data-de...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	117. "Релиз GNU tar 1.30"	–1 +/–
	Сообщение от VINRARUS (ok), 20-Дек-17, 00:34
	>основная фишка в нахождении дублирующихся _кусков_ (а не просто блоков, как например в zfs или целых файлов, как в squashfs) данных вариативной длины. Это ж какие размеры используемой оперативки должны быть при упаковке? В блочной дедупликации все просто и быстро с кс, а тут какое мин. количество байт участвует в дедупликации?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	118. "Релиз GNU tar 1.30"	+1 +/–
	Сообщение от Аноним84701 (ok), 20-Дек-17, 01:57
	>>основная фишка в нахождении дублирующихся _кусков_ (а не просто блоков, как например в zfs или целых файлов, как в squashfs) данных вариативной длины. > Это ж какие размеры используемой оперативки должны быть при упаковке? В блочной дедупликации все просто и быстро с кс, а тут какое мин. количество байт участвует в дедупликации? Там в основном оперативка под индексы уходит, а данные полностью в ОЗУ держать нет нужды. Eсли брать zbackup, то примерно 2МБ на ГБ данных в репе, автор http://zbackup.org/ см. "Scalability" говорит о примерно 1ГБ ОЗУ на 1ТБ репы.
	Ответить \| Правка \| К родителю #117 \| Наверх \| Cообщить модератору


	123. "Релиз GNU tar 1.30"	–1 +/–
	Сообщение от VINRARUS (ok), 20-Дек-17, 02:59
	>>>основная фишка в нахождении дублирующихся _кусков_ (а не просто блоков, как например в zfs или целых файлов, как в squashfs) данных вариативной длины. >> Это ж какие размеры используемой оперативки должны быть при упаковке? В блочной дедупликации все просто и быстро с кс, а тут какое мин. количество байт участвует в дедупликации? > Там в основном оперативка под индексы уходит, а данные полностью в ОЗУ > держать нет нужды. Ну так ясно. > Eсли брать zbackup, то примерно 2МБ на ГБ данных в репе, автор > http://zbackup.org/ см. "Scalability" > говорит о примерно 1ГБ ОЗУ на 1ТБ репы. Другими словами должен совпадать 1 кб непрерывных данных. Ну да, 16 кб на блок у btrfs это немного не то. :)
	Ответить \| Правка \| К родителю #118 \| Наверх \| Cообщить модератору


	56. "Релиз GNU tar 1.30"	–1 +/–
	Сообщение от Борщдрайвен бигдата (?), 18-Дек-17, 13:52
	Так и что плохого в архивах по паре сотен гб где-то в s3, например?
	Ответить \| Правка \| К родителю #43 \| Наверх \| Cообщить модератору


	66. "Релиз GNU tar 1.30"	+/–
	Сообщение от Crazy Alex (ok), 18-Дек-17, 16:33
	Да ничего, но товарищ там зачем-то листинги хочет и частичную распаковку. Не помню, когда оно нужно было.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Релиз GNU tar 1.30"	–1 +/–
	Сообщение от Greg KH (?), 18-Дек-17, 19:26
	> зачем-то листинги хочет хватит лицемерить. Неужели, желание списка файлов в архиве - это такой жупел, что меня готовы уже вiндузятником объявить, лишь бы не признать, что tar (и gz) - убоги в качестве дефолтного решения, и используется только потому, что нет альтернативы. > зачем-то листинги хочет Ты себе макбук купил что ли? Симптомы больно похожи: ответ "ненужно" на вопрос о тривиальной фиче, которой нет в системе, и брызганье слюной после появления этой фичи в следующем релизе.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	81. "Релиз GNU tar 1.30"	+1 +/–
	Сообщение от Борщдрайвен бигдата (?), 18-Дек-17, 20:36
	Так ведь tar не особо для этого. Собрать файлы в один, положить на ленту и забыть до Рагнарёка.
	Ответить \| Правка \| К родителю #66 \| Наверх \| Cообщить модератору


	65. "Релиз GNU tar 1.30"	+1 +/–
	Сообщение от Анонимм (??), 18-Дек-17, 16:32
	>>> tar быстро и без фокусов упаковывает их в контейнер >> да >>> с которым потом удобно работать >> нет (see #41 ) > Если У Вас 100GB в архивах, то Вам явно необходимо что-то менять в консерватории. Отлично: не держать слишком больших архивов, потому что с ними неудобно работать и писать что все прекрасно работает и поэтому ничего менять не надо (а у кого работает не очень, тот конечно же ССЗБ). Напоминает яблочное "Вы просто свой айфон неправильно держите!" Из того же dump архива, хотя он тоже изначально "кассетный", бэкапы отдельных файлов восстанавливаются только влет. Но tar был бы удобнее из-за отсутствия привязки к конкретной ФС. Может просто стоит признать, что времена хардов на 100МБ безвозвратно ушли и современные требования к архивам немного изменились?
	Ответить \| Правка \| К родителю #43 \| Наверх \| Cообщить модератору


	69. "Релиз GNU tar 1.30"	–1 +/–
	Сообщение от Аноним (-), 18-Дек-17, 17:45
	> Из того же dump архива, хотя он тоже изначально "кассетный", бэкапы отдельных > файлов восстанавливаются только влет. Но tar был бы удобнее из-за отсутствия > привязки к конкретной ФС. "Влет" это как? Смонтировать через losetup, и скопировать необходимый файл? Ну, тогда да! Тогда пишите tar_fs с опциями gz, bz2, lzma, ... Правда скорость на мой взгляд будет, ну Вы поняли ;) > Может просто стоит признать, что времена хардов на 100МБ безвозвратно ушли и > современные требования к архивам немного изменились? Да! Но это не значит, что tar необходимо выкинуть.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "Релиз GNU tar 1.30"	+2 +/–
	Сообщение от Анонимм (??), 18-Дек-17, 19:16
	> "Влет" это как? Смонтировать через losetup, и скопировать необходимый файл? Ну, тогда да! дамп в смысле "высокоуровневого", сделанного через утилиту dump. Влет, это подключить терабайтный хард с бэкапами к ноуту без USB3 и запустив restore -if на 100ГБом дамп-архиве, выбрать интерактивно файлы для восстановления и восстановить их. За пару минут, а не полчаса. Так же неплохо работает с пожатым дампом, если использовать блоковое сжатие. > Да! Но это не значит, что tar необходимо выкинуть. Вообще-то ветка ветка начинается с #30, где пишут о > с которым потом удобно работать. Или усомниться в безоговорочности удобства работы с tar в современных реалиях (и юзкейзах) уже сам по себе призыв к выкидыванию?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	75. "Релиз GNU tar 1.30"	–1 +/–
	Сообщение от Greg KH (?), 18-Дек-17, 19:30
	> Ну, тогда да! Тогда пишите tar_fs с опциями gz, bz2, lzma, . Вы реально настолько некомпетентны, не понимаете, почему dump-архив позволяет вытаскивать файлы быстро, а tar-архив - не позволяет? Ну так вы спросите сначала, может быть поймете, и не будете невежеством бравировать.
	Ответить \| Правка \| К родителю #69 \| Наверх \| Cообщить модератору


	96. "Релиз GNU tar 1.30"	+1 +/–
	Сообщение от Аноним (-), 19-Дек-17, 09:35
	>> Ну, тогда да! Тогда пишите tar_fs с опциями gz, bz2, lzma, . > Вы реально настолько некомпетентны, не понимаете, почему dump-архив позволяет вытаскивать > файлы быстро, а tar-архив - не позволяет? Ну так вы спросите > сначала, может быть поймете, и не будете невежеством бравировать. Спасибо, за публичную порку ;) Так давно это было, что аж успело забыться. Еще раз посмотрел man dump и просторы Интернета. В очередной раз понравилось. К сожалению пока ручки не дошли. Все по старинке tar, rsync. Но очень необходимо себя заставить изучить dump and duplicity, и сравнить (особенно в вопросе инкрементального backup-а).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	98. "Релиз GNU tar 1.30"	–2 +/–
	Сообщение от Greg KH (?), 19-Дек-17, 11:19
	Спасибо за адекват, анонимус > изучить dump and duplicity Мне вообще странно, почему dump не особо популярен в linux, тогда как в bsd dump это мейнстрим. А duplicity оставляет двоякое впечатление Мне понравился borg backup из относительно свежего последного
	Ответить \| Правка \| Наверх \| Cообщить модератору


	103. "Релиз GNU tar 1.30"	+/–
	Сообщение от Аноним (-), 19-Дек-17, 13:42
	> Спасибо за адекват, анонимус >> изучить dump and duplicity > Мне вообще странно, почему dump не особо популярен в linux, тогда как > в bsd dump это мейнстрим. > А duplicity оставляет двоякое впечатление > Мне понравился borg backup из относительно свежего последного Мне вообще кажется, что достаточно важно в этом вопросе это то, что система позволяет сразу после (или в течении) процесса обновления (создания) копии, сможет сделать unattended верификацию всей (или случайной части) сохраненной в резервной информации с оригиналом. И самое главное, в случае, если что то пошло не так, отправит сообщение (обязательно зашифрованное) на указанный в настройках системы адрес электронной почты (лучше на несколько ;) В принципе все выше озвученное не так сложно реализовать путем скриптования (ну скажем на shell). Просто должен найтись Человек, который с удовольствием, реализует начальный функционал в течении выходных! Позже, может кто то подключится и допилят.
	Ответить \| Правка \| Наверх \| Cообщить модератору