Comments 14
Образность притомила. Устал продираться через Савелиев и Аристофанов к сути. Только на середине текста вы дошли до термина "инкрементальный" (я ждал его с первой строчки).
Бросил читать. Художественный приём в этом случае выбран далеко не лучший.
+8
А мне, как мобильному разработчику, иногда заглядывающему по ту сторону API, вполне зашло. Переживал за Савелия.
+4
А я ждал планирования бэкапов от PRO/RTO и не дождался в явном виде.
+1
Всё верно, в явном виде в статье этого нет. Одна из причин заключается в том, что цель — это донесение мысли «Бэкапы важны, бэкапы нужны. Не забывайте проверять и восстанавливаться», но при этом очень не хотелось получить на выходе «очередной скучный доклад(статью) про бэкапы», коих, признаться честно, я видел довольно много.
Если хочется поговорить подробнее по данной тематике, то есть отличное место — https://t.me/pro_ru_bareos. Савелия там, конечно, не найти, а меня вполне.
Если хочется поговорить подробнее по данной тематике, то есть отличное место — https://t.me/pro_ru_bareos. Савелия там, конечно, не найти, а меня вполне.
+1
Bareos просто умеет хранить файлы, больше он ничего не умеет. Чтобы сделать бэкап базы бареосом, нужно или писать скрипт, который сам делает бэкап базы и подсовывает бареосу файлы (то есть костыль) или использовать официальные питоньи модули бареоса, которые написаны через одно место или совсем заброшены авторами (почемуто нет модуля для mysql, но есть модуль для mariadb). Причем нет никакой гарантии что ты сможешь восстановиться с таких бэкапов.
+2
Тот неловкий момент, когда почувствовал себя Аристофаном
Впрочем, удачи им с Савелием
+3
Читай Савелий про ZFS: снапшоты, send/recieve, scrub, compression, и тп, и будет тебе спокойный сон. =) (PS только, Савелий. Никогда. Не включай. Дедупликацию.)
+1
Никогда. Не включай. Дедупликацию.
почему это? у меня включено, например, на фс с бэкапами виртуальных машин, отлично себя показывает.
dedup: DDT entries 17291644, size 525B on disk, 169B in core
bucket allocated referenced
______ ______________________________ ______________________________
refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE
------ ------ ----- ----- ----- ------ ----- ----- -----
1 10.9M 10.9T 2.87T 2.68T 10.9M 10.9T 2.87T 2.68T
2 1.73M 1.73T 762G 706G 3.79M 3.79T 1.60T 1.49T
4 512K 512G 185G 172G 2.66M 2.66T 988G 918G
8 586K 586G 254G 235G 6.12M 6.12T 2.58T 2.39T
16 2.67M 2.67T 623G 585G 53.4M 53.4T 12.1T 11.4T
32 107K 107G 17.5G 16.6G 4.20M 4.20T 730G 691G
64 2.81K 2.81G 1.62G 1.49G 260K 260G 153G 141G
128 827 827M 552M 509M 132K 132G 85.2G 78.6G
256 214 214M 86.8M 80.3M 71.6K 71.6G 28.6G 26.5G
512 73 72.0M 26.9M 24.9M 57.6K 57.0G 21.8G 20.2G
1K 81 81M 33.2M 30.8M 118K 118G 47.7G 44.2G
2K 54 54M 18.0M 16.7M 128K 128G 41.2G 38.4G
4K 11 11M 4.61M 4.26M 45.6K 45.6G 19.1G 17.7G
8K 1 1M 4K 9.14K 15.1K 15.1G 60.4M 138M
32K 1 1M 4K 9.14K 38.9K 38.9G 156M 355M
Total 16.5M 16.5T 4.67T 4.36T 81.9M 81.9T 21.2T 19.9T
P. S. я в курсе про проблемы дедупликации в ZFS, но вот «никогда» — это вы лишнего хватили.
+2
Осталось какое то ощущение дежавю.
+1
Про dedup и zfs.
Рекомендую поискать про redhat vdo (собирается и для deb-подобных). И попробовать развернуть zfs поверх vdo предварительно отключив сжатие на zfs — этим займется vdo.
Что это дает? У vdo ЗНАЧИТЕЛЬНО меньше накладные расходы для ram на dedup.
ЗЫ. Рассчитать эффект от deduplication в zfs habr.com/ru/post/328048/#comment_10208284
Рекомендую поискать про redhat vdo (собирается и для deb-подобных). И попробовать развернуть zfs поверх vdo предварительно отключив сжатие на zfs — этим займется vdo.
Что это дает? У vdo ЗНАЧИТЕЛЬНО меньше накладные расходы для ram на dedup.
ЗЫ. Рассчитать эффект от deduplication в zfs habr.com/ru/post/328048/#comment_10208284
0
Sign up to leave a comment.
Восстановление данных в современной инфраструктуре: как один админ бэкапы настраивал