Как стать автором
Обновить

Комментарии 241

ЗакрепленныеЗакреплённые комментарии

Спасибо за ваш отзыв. Я понимаю, что несмотря на доступность списка служебных контейнеров и управления ими в API S3, наш продукт имеет потенциал для дальнейшего развития. Мы обязательно учтем ваше замечание и добавим соответствующую функциональность в нашу Панель Управления в ближайшее время.

Что касается обработки «абортов» и управления оставшимися сегментами. Я уверен, что мы не имеем права самостоятельно, на своей стороне, решать, удалять нам или нет часть вашей информации (даже если она служебная). Дело в том, что со стороны продукта мы никогда достоверно не знаем, как поведет себя ваше ПО: начнет загружать объект снова или вызовет «комплит мультипарт аплоад» и дозагрузит недостающую часть.

Мы изучим логи и внимательно разберем вашу ситуацию. Спасибо, что помогаете нам делать сервис лучше!

Увы, у Selectel оказался один глубоко спрятанный под капотом недостаток. Идея была хороша, реализация - плохая.

Я бы поменял название статьи в целом

Держитесь подальше от Selectel

Ну не знаю, один клиент их виртуальный сервер нормально использует.

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

нет, там у него развернуты какие-то программы.

а что Вы имеете в виду, подскажите, пожалуйста?

Я имею в виду, что Selectel как российская компания обязан участвовать во всяких СОРМах

привыкайте. мы живем в эпоху утраты приватности. селяви

В современных реалиях эта статья является максимально неактуальной, а в местах сильным навалом кринжа. По факту из реально полезного только пункт 8 применимый к любому среднему-крупному бизнесу. А по статье автора можно нарисовать картину как технически неграмотный человек (в этом моменте) рассказывает ТП как должен работать их сервис. Но вы вроде платили за "хранение" файлов, а не за администрирование хранилища. Вы сами выбрали S3 API для загрузки данных недоконца разобравшись в тонкостях и перекладываете ответственность на сервис. Как-то не ice получается(

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

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

Это не недостатки исполнителя, это непонимание концепции multipart в контексте концепции облачного хранилища.
Вот статья от AWS, где все та же "проблема" описана в деталях. Допиливать реализацию CEPH (подозреваю, на нем все) можно конечно, но, кажется мне, нецелесообразно: если клиент оборвал соединение, стоит удалять остатки мультипарта? А через какое время?
Про "техническую сложность транзакций" — улыбнуло.
Название статьи лучше бы переименовать в "Держитесь подальше от 1С, если у вас нет своего штата разработчиков" или "Контроллируйте работу своего клиента при работе с облаком".

Т.е. ситуация, когда есть некий "служебный контейнер" который не отображается но тарифицируется это норм? Ясненько, понятненько.

Соответствует спеке S3? Вполне. Остальное на усмотрение разработчика клиента и хостинг-провайдера.

Раз товарищ не осилил почитать документацию того, чем пользуется и где-то у себя в голове самостоятельно решил "как это должно работать" - имхо, ССЗБ.

А в спеке написано что он входит в тариф? Спека это только техническая часть. А клиент возмущен тем что с него денег хотят больше чем в тарифе указано. Проблема не в незнании клиентом спеки S3, а в организации прозрачности процесса продажи клиенту услуги. То есть отсутствии этой самой прозрачности и наличии скрытых факторов.

вот именно.

Соответствует спеке S3? Вполне.

Вас не затруднит привести цитату из спеки где написано что в личном кабинете надо объем услуг отображать без учета служебного контейнера, а счет выставлять исходя из полного объема?

Заказываешь килограмм колбасы в интернет-магазине за 500 рублей, тебе привозят килограмм колбасы и счет на 50 000 рублей. А на вопрос "какого хрена?" выясняется что в счет входит вес курьера с электросамокатом потому что вы ему "до свидания" не сказали и он вас на лестничной площадке неделю ждал.

S3 к личному кабинету никакого отношения не имеет.

Что Селектел учитывает недокачанное в общем объёме и не даёт никак легко это почистить - недостаток их сервиса, но и только. Это не повод ныть, как автор поста, насчёт того, что "S3-хранилища совершенно не подходят для бэкапов".

я "ною" конкретно про Selectel. И точнее - для простой организации бэкапов. Если вы знаете, как бэкапить через коммандную строку без лишних геморроев, Welcome. Пока что тут не озвучен метод.

У нас уже который год бэкапится масса всего в S3 банальным s3cmd put. Специально для вас сейчас зашёл и проверил бакеты - ровно ноль байт недокачанных файлов.

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

плохой из вас тестировщик.

S3 хранилища совершенно не подходят для бекапов. CEPH. Более того, строго противопоказано осуществлять резервирование на S3. В стране в лучшем случае дюжина человек умеет правильно обращаться с этими хранилищами. Какова вероятность, что у селектела такой человек имеется? веротностная выборка говорит, что эта фишка у них на аутсорсе;)))

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

вот и мне интересно.

а в чем проблема использования такого хранилища?
если надо скачать файл, человек заходил в ЛК и скачивает бэкап.
сам процесс бэкапа это тупо вызов RCLONE
проблема только с удалением фрагментов.

Если вы используете или планируете использовать холодное хранилище Selectel для бэкапа

Задача решается готовым VDS с большим диском. Разумеется, помимо облачного бэкапа, должен быть ещё и бэкап на физическом NAS, а ещё, желательно, офлайновый бэкап на физическом диске в несгораемом сейфе.

А подобные "холодные хранилища" - это инфраструктурные продукты для более сложных (и дорогих в разработке) вещей.

нужно просто допилить нормальную транзакционную передачу. Если этого нет то да, для бэкапа это бесполезно.

В случае с мультипартом селектел действует абсолютно правильно. Если вы решили отменить мультипартовую загрузку - для этого в API S3 есть соответствующая функция.

https://docs.aws.amazon.com/AmazonS3/latest/userguide/abort-mpu.html

То, что вы не знаете этого, это ваша проблема а не селектела.

и как же мне вызвать это API и главное - зачем?

я покупаю хранилище у Селектела, а не у Амазона.

Рассчитываю на хранение данных, тестирую - вроде все ок. А потом вскрываются подводные камни.

Вы покупаете хранилище, доступное по некоторому API. И вам обещают, что оно будет корректно отвечать на запросы через это API.

пользовательский ui это тоже API

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

да. не надо списывать на пользователя свою лень. ;-)

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

Я не понимаю все же плюсов от таких хранилищ, неужели это гораздо дешевле и удобнее чем просто пару пк с пачкой дисков и ибп. Ну или вообще просто 1с фреш?

а если случится пожар или маски-шоу и т.п?

Настрой у себя дома файловое хранилище на десяток другой террабайт для постоянных клиентов.

Отличная идея — хранить бухгалтерскую информацию, а то и ПД у себя дома /s

была такая мысль. Но слишком шумно.

если будут маски-шоу, вы сами им все отдадите, и не важно где это находится, вот вообще не аргумент

Мой дед был партизаном. а я что, паяльника убоюсь?

я работал в компании где одним из собственников был бывший опер ) он рассказывал сколько таких "смелых партизан" повидал )

От организации процесса зависит.
Можно сделать всё так, что ни кто из участников маски-шоу просто не будет иметь пароля от системы и даже не будет знать, где этот пароль взять. А пока следователь выполнит квест по поиску пароля, оставшиеся соучастники удалят пароль из места хранения.
Вопрос лишь в том, что будет если пароль "случайно потеряется"...

если будут маски-шоу, вы сами им все отдадите

Так проблема то не в этом. У вас могут изъять сервер, порыть его месяц, ничего не найти, извиниться и вернуть... не весь. Вот тут то и неплохо иметь бэкапы где-то, откуда оборудование не вынесут и из него случайно что-нибудь не пропадет.

роют не идиоты, они увидят куда делались бакапы, далее запрос в ЦОД и ЦОД все отдает ) а еще проще устроят допрос с пристрастием админу, он сам все и выдаст, тут решают не технологии, а человеческий фактор, человек тут слабое звено

Отдаст-то отдаст, главное что не удалит.

Я сразу в сообщении написал, что проблема не в том что отдаст, а в том, что сотрудники полиции могут данные просто потерять, и у вас будут лишние проблемы, даже если в итоге дело закроют, а в ЦОДе они останутся. Знаю историю, где именно так и было -- просто вернули сервер без дисков.

жизнь продолжается

всякое случается

бывает стреляют

и убивают

А по-моему классная у них поддержка, судя по выложенному диалогу.

Возможно, но проблему не решила и с менеджером не связала. Пришлось выносить этот сор на публику. Увы. Да и мне не особо улыбается сейчас у трех клиентов менять схему бэкапа.

Доброй ночи! На самом деле, с менеджерами можно легко связаться с помощью нашего Telegram-чата Selectel Community: https://t.me/SelectelCommunity

Достаточно задать вопрос по интересующему продукту. Как показывает практика, коллеги там отвечают довольно оперативно.

ну я то об этом не знал, я даже телефон свой оставил (в переписке). Да и по тону общения было видно, что я крайне разочарован.

Спасибо за ваш отзыв. Я понимаю, что несмотря на доступность списка служебных контейнеров и управления ими в API S3, наш продукт имеет потенциал для дальнейшего развития. Мы обязательно учтем ваше замечание и добавим соответствующую функциональность в нашу Панель Управления в ближайшее время.

Что касается обработки «абортов» и управления оставшимися сегментами. Я уверен, что мы не имеем права самостоятельно, на своей стороне, решать, удалять нам или нет часть вашей информации (даже если она служебная). Дело в том, что со стороны продукта мы никогда достоверно не знаем, как поведет себя ваше ПО: начнет загружать объект снова или вызовет «комплит мультипарт аплоад» и дозагрузит недостающую часть.

Мы изучим логи и внимательно разберем вашу ситуацию. Спасибо, что помогаете нам делать сервис лучше!

ну ретеншен поличи можно же сделать, чтобы не вечно эти остатки болтались, а какое-то желательно настраеваемое время

но как видите это не сделано, в итоге клиент переплачивает.

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

сделайте нормальный синхронизатор, чтобы откатывал файлы в случае обрыва. Сейчас пользоваться Rclone невозможно. У одного клиента даже лимит превышен был контейнера (но там обещали вернуть деньги за превышение). Другие платят больше чем должны из-за служебных фрагментов. А как это чистить непонятно. и главное - зачем, ведь потом опять появятся эти обрывки.

Скажите, а Rclone -чей продукт? Почему Selectel вдруг вообще стали виноваты в том, что Rclone оставляет за собой "мусор"?

Радик неувиновен, спору нет.

Но Selectle рекомендует Rclone.

Если бы он честно и прямо написал, что Amazon S3 - это только для большого IT, а для простой архивации не годно, т.к. кривое, косое и сложное, я бы его и не использовал.

А в итоге получается, что мы с поддержкой пришли к выводу, что у них нет простого сценария для архивации. Импотенция, так сказать - отсутствие возможности.

Это не для большого IT, а для тех кто знает за что держать, куда смотреть и на что нажимать. Или, хотя бы, имеет привычку изучать документацию.

Если вы не владеете такими навыками, то, например, можно просто посмотреть видео в отпуске на десятки тысяч долларов, получить хук перфоратором и перелом шеи со смещением, или просто получить в бочину поездом.

обычно есть вещи, которые ожидаешь от сервиса.

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

скажем так, общепринятые практики облачных хранилищ данных

Если уж проводить аналогию с унитазом — так с ним надо время от времени использовать ершик и спецсредство.

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

Выкачать файло, прохешировать поблочно на манер торрента, грохнуть всех, выкачать повторно и посмотреть, что выживет.
Данных у вас там не петабайты, идея вполне реализуемая. Тем более, что вы где-то в сиблингах рапортовали, что ничего не поменялось с конечным сальдо в 300ГБ или около того

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

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

я определился. это запасной архив.

конечно, нужно чтобы он был в рабочем состоянии.

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

Только вот прикол в том, что S3 - это и есть общепринятая практика облачных хранилищ данных...

на яндекс-диске я подобного беспредела не встречал. Видимо, вы говорите о холодных хранилищах, а не об обычных?

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

Для себя лично не нашел ничего лучше чем сделать домашние сервера на которых развернуть все нужные сервисы.

это да, ЯД нормально работает только через приложение ЯД. Но оно не стартует как сервис, не поддерживает заявленный WebDav и т.п., поэтому от него отказались.

Че эт? WebDav в ЯД прекрасно работает

здрасьте. он имитирует работу, при передаче файлом более 100 Гб начинает зависать.

Ну что вы "грузите" то? Это элементарная "галочка" в настройках. Что-то типа "удалять недозагруженные файлы через Х часов". Делается элементарно через крон (да, я намеренно утрирую, но вас толпа народа, вы в состоянии сделать как вам нужно). Просто скажите прямо: "Менеджмент нам запретил это делать, т к это нам не выгодно". Зачем врать то?

ПС: внизу вон пишут, что у амазона это сделано.

У Амазона сделана не "галочка", а возможность управления политиками жизненного цикла. Сами политики ещё кто-то должен написать, и если использовать подход "я думал это просто сетевой диск" - проблема будет ровно та же самая.

вот именно. если Амазон - настолько кривая система для архивации, то проще все же поискать другое холодное хранилище или использовать не холодное.

вот именно. если Амазон - настолько кривая система для архивации

Я честно вас не понимаю, вы просто выбрали инструмент не подходящий под ваши задачи. Стоило просто разобраться как работает S3 прежде чем использовать. Если работать используя "метод тыка", можно куда больше денег потерять, и данные в придачу.

а чем он не подходит? Только мусором. Если бы мусор не образовывался, был бы идельный инструмент.

Ну да, в итоге, как написали ниже, Rclone тоже подходит для бэкапов в S3, просто нужно было его с правильными ключами запустить :)

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

А что мешает с юридической точки зрения добавить в личный кабинет функцию "Очистить недогруженные фрагменты файлов", и подтверждение с описанием возможного риска и галочкой "я понимаю риск, продолжить". Если клиент (юзер) поставил галочку и удалил хвосты, то дальше на его совести, как поведёт себя клиент (ПО).

Меня в гуглодиске это дико бесило, что загруженные через API, но удалённые в дальнейшем через веб-интерфейс файлы могут стать orphaned и занимать при этом место, но никакого внятного интерфейса для их очистки не было (т.к. в папке они не отображались, но продолжали существовать), приходилось скрипт писать, который через API вынимал список всех файлов и удалял те, на которых нет ни одной ссылки в папках. Как сейчас там с этим делом, не в курсе.

Для объективности было бы неплохо изучить как обстоят дела с этим в других Amazon S3 совместимых облаках. Например у яндекса или у самого амазона. Пока выглядит как недостаток архитектуры by-design а не как косяк селектела.

Я их не защищаю, сам от них съехал после грандиозного факапа лет пять назад, когда у них несколько дата-центров лежала. Но по приложенной переписке работа поддержки приятно удивила)

Посмотрите на syncthing для резервного копирования. Просто работает, я доволен как слон.

я другие не щупал. Но если это так, что весь Amazon S3 не годен для простого бэкапа. И это то, что при входе и не заметишь. Вроде бэкапит, вроде все хорошо, а потом вскрывается, что пользоваться этим совершенно невозможно...

syncthing - это я так понял софт, а не облако? или вы имеете ввиду, что он может обходить описанный косяк Amzon S3?

syncthing – это софт, который настраивается на двух машинах (на тачке, имеющей доступ к файлам БД жопы одина, и на машине, куда вы будете делать бэкап). Транзакционность, докачка, восстановление с середины – всё есть

на мой взгляд, чрезмерно усложнено.

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

Он решает задачу "синхронизировать два каталога".
Как Dropbox/Drive (любой)/Box, но вместо облака – другая машина.
Настраивать сеть, ставить демона, заставлять машины видеть друг друга не нужно, там DHT-сеть от BitTorrent.
Но да, он решает задачу синхронизации двух каталогов (включая, например, телефон), а не бэкапа.

Но да, он решает задачу синхронизации двух каталогов (включая, например, телефон), а не бэкапа.

Ну там и слепки есть, и синхронизация в одну сторону.

Да я oldscool, мне robocopy было достаточно всегда. ;-)

Я на CMD напишу нужный архиватор. Но мне нужна утилита командной строки для Amazon S3 вроде rclone, но не засоряющая диск.

Для этого вам надо все таки сесть и разобраться с API S3. А не перекладывать свои проблемы на других. "Я думал, что это просто сетевой диск" - это не аргумент.
Я к Селектелу никакого отношения не имею, если что...

этим мы тут и занимаемся. пытаемся найти несложный метод пролечивания.

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

Syncthing шикарная штука, но я бы не рекомендовал её как средство для коммерческого бекапа. Там нет снепшотов и полных версий. Если версию последнюю восстановить ещё можно, то с восстановлением версии "месяц назад" могут возникнуть проблемы.

Там есть история версий с настройкой по числу копий или по времени. Хотя лично я Syncthing не для бекапа использую, а по назначению - для синхронизации.

Для бекапа у меня rdiff-backup (и ещё кое где tar). Ну его-то данные в S3 не положишь, нужна нормальная ФС.

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

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

Но я рассматриваю Syncthing как средство гарантированной доставки дампов баз или локального состояния файлового хранилища до сервера бэкапов. А там уже локально оно хранится с той глубиной которая мне нужна.

То есть в случае с 1с снимаю дампы sql или выгружаю файловую версию, на месте ее шифрую, а потом отдаю Syncthing, который сквозь все NATы доставляет ее до одного или даже нескольких в критических случаях хранилищ. И там раскладываю.

В Amazon S3 недозагруженные объекты (файлы) хранятся в той же корзине (bucket). Можно создать правило (lifecycle rule), которое их чистит.

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

А чем вы его монтируете, кстати? s3fs?

я не монтирую. я тупо использую rclone для синхронизации файлов, рассматривая при этом контейнер как диск. даже не думал, что там такие заморочки.

Я вполне поверю, что проблема в реализации временных файлов у rclone, а не у селектела. Впрочем, спеку на S3 не читал, особенно на серверную часть (с клиентской хотя бы работал через s3fs и boto@python)

но в итоге у S3 нет никаких вменяемых инструментов командной строки для синхронизации.

Есть s3cmd, minio-client как минимум. При этом они же позволяют настроить удаление лишнего.

каким образом позволяют?

Через ключи или через установку политик life circle

а по-подробнее.хотя можете и не объяснять. Это чрезмерное усложнение для сервиса, где должно все просто копироваться.Прервалась связь с источником - все, фрагменты будьте добры удалитесь.

... и копируйтесь 100 терабайт снова с нуля ? денег не жалко ?

фрагменты на то и фрагменты, что заливаются независимо и "собираются" в один файл отдельным вызовом апи.

мало того, при желании можно заливать по кусочку в день, а собирать раз в месяц.

а вот отсутствие lifecycle у селектела при "совместимости с S3" - это да, косяк

у меня нет 100 терабайт. Объемы поменьше.

Ну так вы ж говорите о том, как, по вашему, должен работать сервис.

А он не только для вас :)

а почему сервис не может быть гибким? Для меня проблема только в чистке не переданных сегментов.

Welcome to real world.

Облачные технологии это не отсутствие компьютера/сервера. Это компьютер/сервер у кого-то Другово.

Сетевой диск это не «как обычный диск только побольше» это другая система и другой уровень проблем.

Только сетевой диск в NFS работает на основе кода, который вы можете скачать, прочесть и собрать; сетевой диск в CIFS (SMB) работает на основе кода, который используют тридцать лет, его можно дизассемблировать, к нему есть вылизанный тысячами пользователей и разработчиков MSDN; а сетевой диск в S3 работает как-то, к нему написано руководство, которое, может быть, соответствует реальности. Или не полностью.

С Яндекс-диском у меня никогда таких проблем не было. Пока они не стали перекрывать кислород маркетинговыми уловками и не задушили WedDav

Если вам нужен аналог Яндекс-диска, посмотрите на Nextcloud как прослойку между вами и s3. Только нужно будет иметь в виду необходимость бэкапов самого Nextcloud...

мы вроде уже нашли метод, чистить 2х дневные файлы в служебном контейнере. Задал вопрос селектелу.

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

нет уж, меня такая непредсказуемость не устраивает.

Селектел скатился в последний год, видимо нормальные админы разбежались после начала чего-то-там. Но цены для РФ всё равно "лучше всех" если ловить дедики на аукционе со скидкой 30-35%

Тут говорят, проблема не в Селектел, а в протколе S3 Amazon.

конечно же проблема и в selectel, и в протоколе s3. но уж точно не в том, каким образом вы его стали использовать :))

а чем плохо такое использование. Разве холодное хранилище не идеально для бэкапа?

Концептуально - идеально, но нужен ещё и клиент, который умеет с ним работать не оставляя мусора.

да. а клиента то нетуть...

Клиент есть, только к нему, как подсказывают ниже, тоже надо документацию читать. Хоть и запрятали там её в довольно неочевидное место.

в том то и дело, что что-бы что то искать, надо предполагать его существование. а тут не ожидаешь никаких граблей.

оно очень удобно. да. но, как и со всем остальным, иногда надо поизучать вопросы "а как эта штука работает", "а как ей правильно пользоваться" итд.

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

у меня нет бюджета изобретать костыли.

я проверил - S3 непригодно для простого бэкапа. Слишком много геморроя на пустом месте.

я с таким сталкивался у других провайдеров. Это не (только) селектел.

надеюсь мы найдем, как это лечить.

Краткий вывод - использовали инструмент, функционал которого не изучили.

вы еще скажите это фича

Это определённо баг, но не в s3. Это баг в Rclone.

Других инструментов командной строки для S3 нет. Значит S3 в целом бесполезна для простой архивации.

эм... их вагон и маленькая тележка включая официальный от амазона

например? (мы про утилиты командной строки для синхронизации данных)

зачем нужен Rclone если есть s3cmd, да?

и что я должен оттуда понять?

насколько я понял читать вы не хотите, поэтому вот вам готовая инструкция на русском от chatgpt

@echo off
REM Получить список всех незавершенных multipart загрузок и сохранить в temp файл
aws s3api list-multipart-uploads --bucket your-bucket-name --profile your-s3-compatible-service --query "Uploads[*].[UploadId, Key]" --output text > uploads.txt

REM Прочитать temp файл и удалить каждую незавершенную загрузку
for /F "tokens=1,2" %%A in (uploads.txt) do (
    echo Aborting upload ID %%A for key %%B
    aws s3api abort-multipart-upload --bucket your-bucket-name --key %%B --upload-id %%A --profile your-s3-compatible-service
)

REM Удалить temp файл
del uploads.txt

pause

bat скрипт для удаления старых multipart загрузок

не, это геморройно. Я еще понимаю запустить Rclone с ключом, но парсить файл - увольте-с.

…сказал человек, который обещал в одном из комментариев всё на пакетных файлах написать если ему дадут клиент для командной строки.

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

мимо кассы. Я уже писал, что незавершенные загрузки rclone не удаляет.

Kopia, duplicati и т.д.

Спасибо кэп. Только эта фишка не на поверхности, а глубоко под капотом.

600 рублей..

Кажется, что многие, кто сегодня открыл эту статью сильно больше зарабатывают в час..

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

Никогда не использовал селектел, и скорее всего никогда не буду. Но 600 рублей - это конечно сильно, особенно для заголовка - "Держитесь подальше от холодных хранилищ Selectel".

Почитал как отвечает поддержка селектела и мне наоборот захотелось к ним перейти?‍♂️

Поддержка там хорошая, но увы, использовать холодное облако S3 для бэкапа "по-простейшему" невозможно.

Там накопительный эффект. За год уже 6.000. Да и в конечном итоге яндекс-диск дешевле.

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

Я посчитал за свою жизнь, получилось 240.000. Так как нельзя брать последнее для подсчёта среднего, взял курс доллара на середину жизни (~28.5) получилось чуть больше 8421, но т.к. мы живём сегодня и в России и сегодня, я посчитал обратно на сейчас по текущему курсе и получилось 757.900. Накопительный эффект решает. А если ещё добавить инфляцию, думаю на двушку около ТТК хватит.

Это же фиксон, широко известный в узких кругах трол

... получается 600 рублей в месяц, это 6.000 в год ...

Мне одному эта фраза кажется странной? )) Вроде 600 x 12 = 7.200, не?

А вообще да, если у какой-либо конторы 600 рублей в месяц это проблема, то вряд ли она решится экономией этих самых шести сотен

в пределе потом это все выливается вот в такие случаи:

https://habr.com/ru/companies/ncloudtech/articles/783564/

"как съэкономить поллимона $ в год, изменением одной дефолтной настройки"

да, не стоит пускать на самотек такое.

да. вы буквоед.

проблема решится, тем более что таких конторы три.

суммарно уже эффект получше.

а если умножить на пятилетку, сами понимаете.

Копейка рубль бережет.

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

Селектел красавцы, их поддержка просто лучшая. Они имели полное право грубо вас послать читать документацию.

Но разве не должно ограничение срабатывать на все? Поставил 400Гб - больше не загрузишь и не переплатишь.

По мне так логичнее.

тут кстати они лажанулись. Объем контейнера превышен.

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

Как через Rclone мне удалить данные в служебном контейнере?

Вопрос неправильный. У Yandex это делается через политику lifecycle для bucket. Кстати, на той же странице есть упоминание S3 API и XML, а здесь есть тоже упоминание S3 API... В общем, всё это вполне может быть и навешивание политик должно быть возможно автоматизировать через CI pipeline, даже если в веб-интерфейсе или стороннем инструменте этой настройки и нет.

и вот зачем мне все это знать, простому 1Снику? Было заявлено холодное хранилище а в итоге я получил ненужный геморрой.

Я вот так очищаю в s3 yandex в скрипте

# Cleanup incomplete multipart uploads
s3cmd -c .s3cfg multipart s3://$BUCKET_NAME | grep '-[0-9]{2}T[0-9]{2}:' | while read MULT_LINE
do
   MULT_NAME=echo $MULT_LINE | cut -d' ' -f2
   MULT_ID=echo $MULT_LINE | cut -d' ' -f3
   s3cmd -c .s3cfg abortmp $MULT_NAME $MULT_ID
done

поддержка не ответила, как отличать используемые части от неиспользуемых...

так бы я уж удалил, наверное.

да я и не думаю, что это просто.

У меня просто только один скрипт делает синхронизацию раз в сутки. После его отработки можно считать что все недокаченное "не используется"

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

иначе будут удалены сегменты основного контейнера

Может быть под этим и подразумевались "текущие закачки" ?

Не могу придумать что это за сегменты такие.

без понятия. Поддержка изъясняется загадочно.

Ну надо было уточнить - если я точно знаю что в данный момент ничего не закачивается и удалю букет "*_s3multimartuploads" ничего страшного не случится ?

Но задавать правильные вопросы тоже искусство, да )

PS. Предназначение бакета можно понять по его названию

PPS. В селектеле кстати получается проще - можно просто бакет снести, а не искать "недокачки" как у меня в скрипте.

попробую уточнить таким образом.

джва года ищу замену hetzner storagebox
ну нету ни у кого, в тп селектела сказали что "в разработке, а вы пока наше s3 юзайте"
а я не хочу s3, я хочу nfs/sftp...

NFS без Кербероса не шифруется - отличный вариант для передачи данных, да. А SSH есть примерно у всех, берёте жирный сервер и пользуетесь.

далеко не всегда есть смысл шифровать данные (неожиданно правда)
а жирный сервер будет стоить раз в 6 дороже (+/- в зависимости от хотсера) чем storagebox

ну шифровать можно на своей стороне и передавать уже шифрованное

в том числе можно и так
но конкретно мне это хранилище нужно под такую задачу что можно впринципе открыть шару в ro на весь честной 0.0.0.0/0

Видел на гитхабе конвертер sftp /s3 и ещё куча протоколов

Не люблю сомнительные костыли..

да, лучше в чистом виде.

Насыпьте плюсиков человеку. За то что свел переписку в виде таблицы текста, а не простыни скриншотов. Сейчас таких уже не осталось.

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

я думаю попробовать бить на части по 0.3 Гб, если Rclone поддерживает отключение мультипарта. Тогда можно оставить инфраструктуру у клиентов. Только сперва почистить все.

А в телеге ответил, что это сложно.

похоже можно обойтись без бития архивов на части. Можно по идее чистить двухдневной давности файлы в служебном архиве. Сейчас уточняю у поддержки селектела.

но так то да, лень перестраивать на новый архив.

да, это было спонтанное решение. раньше никогда так не делал.

Что я понял из статьи (никогда ранее не использовав Selectel и Amazon S3):

1) Поддержка Селектела отвечает внятно

2) У любой технологии есть внутренние нюансы, поэтому применение любого решения "нужно уметь готовить правильно", хорошо если эти нюансы и способы описаны в документации у того, кто предоставляет доступ к этой технологии.

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

4) Конкретно мысль о том, что селектел что-то там не удаляет, чтобы вытянуть побольше денег с клиентов - это самая бредовая мысль всей статьи. Как явно следует из ответов поддержки, технология загрузки больших объектов по умолчанию использует метод загрузки с возможностью докачки, поэтому для таких загрузок сейчас нет понятия "загрузилось полностью", любой загруженный кусок остаётся на сервере, т. к. после обрыва связи клиент может захотеть продолжить закачку (в данном случае клиент это не человек, а какое то умное ПО, поддерживающее докачку).

есть в ваших словах доля истины. Но у SELECTEL есть как минимум один косяк - они превысили лимит контейнера, за что и обещали вернуть деньги. Остальное лирика...

Жаль что облако S3 не имеет простых и доступных инструментов для своего использования. Замах на миллион долларов, удар на бакс.

Думал чтобы сохранить инфраструктуру, разбивать файлы на части по 0.3 Гб, но ключ  --disable-multipart есть только у s3cmd, у rclone его нет. Это надо переписывать код. Проще поискать другое хранилище.

Вы 20 раз написали, что используете rclone, но, похоже, так ни разу и не прочитали документацию. В доке явно сказано:

If you run rclone cleanup s3:bucket then it will remove all pending multipart uploads older than 24 hours.

https://rclone.org/s3/#cleanup

Думал чтобы сохранить инфраструктуру, разбивать файлы на части по 0.3 Гб, но ключ  --disable-multipart есть только у s3cmd, у rclone его нет. 

Буквально на том же экране:

Multipart uploads

rclone switches from single part uploads to multipart uploads at the point specified by --s3-upload-cutoff. This can be a maximum of 5 GiB and a minimum of 0 (ie always upload multipart files).

Установите предел в 5Гб и закружайте одним куском. 5Гб - ограничение S3 для single part: https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html.

спасибо, проверю. попробую почистить s3:bucket. странно, что поддержка мне об этом не сказала. Попробую выполнить эту команду и посмотрю, уменьшится ли объем служебного контейнера. Тогда буду вызывать ее перед началом архивации.

про разбивку я у них тоже справшивал, есть ли ключ, ограничивающий мультипарт для rclone, не ответили.

Не работает cleanup:

Посчитаем размер основного контейнера 189 Гб:

rclone size backup:backup
Total objects: 60
Total size: 189.032 GiB (202971502109 Byte)

Посчитаем размер служебного контейнера 557 Гб:

rclone size backup:backup_s3multipartuploads
Total objects: 111.661k (111661)
Total size: 557.222 GiB (598312185406 Byte)

Попробуем очистить загрузки старше чем 24 часа, но размер хранилища не уменьшился:

rclone cleanup backup:backup_s3multipartuploads
rclone size backup:backup_s3multipartuploads
Total objects: 111.699k (111699)
Total size: 557.407 GiB (598511414846 Byte)

Так чистить надо там, куда загружали. То есть backup:backup.

Увы, не помогло:

C:\rclone>rclone cleanup backup:backup

C:\rclone>rclone size backup:backup_s3multipartuploads
Total objects: 110.795k (110795)
Total size: 553.439 GiB (594250626612 Byte)

C:\rclone>rclone size backup:backup
Total objects: 60
Total size: 189.033 GiB (202972126739 Byte)


Поддержка пишет:

Что касается cleanup. Если мы правильно понимаем документацию, то эта команда отвечает за очистку объектов, которые ожидают загрузки, то есть есть сценарий, при котором загрузка остановилась и стоит на ожидание завершения. Скорее всего, это как раз тот сценарий при котором клиент загружает файл, сервер с Rclone теряет связь, далее остаются какие то сегменты с подобным флагом или что то подобное. У Вас таких объектов нет + у этих объектов есть лимит по времени, судя по документации это 24 часа. То есть сейчас действительно самым разумным вариантом будет перенести объекты в соседний контейнер, тем же rclone, проверить, что все завершилось исправно и удалить контейнеры с лишними сегментами. После вернуть все как было.

А вы никак не рассматриваете гипотезу, что объекты не удалились потому что мусорных объектов просто не было?

То есть все эти 740 гигов - это и есть реальный размер хранимых бэкапов?

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

Syncthing шикарная штука

У нас похожая ситуация с CDN от Selectel. Соблазнились малой ценой за переданный гигабайт.
По факту пришлось платить за переданные гигабайты пользователям + служебный трафик между нодами, а это было 80%. Если честно первый раз явно столкнулись с такой тарификацией. Т. е. увеличение в стоимости в 5 раз. Ушли.

Те я правильно вижу, что это обсуждение из-за 600 р. Автор, доработайте заголовок Держитесь трали-вали, а ТО ПОТЕРЯЕТЕ 600 р!

Ттк я когда цифры увидел, честно подумал, что я без очков наверное там нулей не вижу, или запятая в другом месте и там 60К.

Поддерже селектела респект.

600 рублей в месяц это 7200 в год. За такие деньги можно 2 Тб яндекс диска иметь, например.
Но ладно если бы он работал, а то он захламляется осколками не переданных файлов и больше не принимает данные.

Никогда не использовал селектел, и скорее всего никогда не буду. Но 600 рублей - это конечно сильно, особенно для заголовка - "Держитесь подальше от холодных хранилищ Selectel".

это 600 рублей в месяц. А если бы речь шла о 600 рублей в час? Для вас бы это тоже было легко и непринужденно? А то ведь и до такой суммы может дойти если лимит контейнера не будет соблюдаться.

Народ, вы кого слушаете?! простого 1Сника? наберите в инетернете кто такой Фиксин. Будите приятно удивлены. Он правильно написал, что он простой 1Сник. Дело было так - ему заказчик поставил задачу на реализацию облачного хранилища. Товарищ, т. к. у него ипотека и содержит кучу дармоедов, не детей уже, берется за любую работу. Заказчик попросит на С++ написать, он и за это возьмется. Так вот он нашел Селектел, установил, настроил его, т. е. втюхнул заказчику. Хотя мог бы отказаться, раз он простой программист 1С.

Тепереча работает все не так как надо, ему заказчки предъявил, мол что за фигня - ты же порекомендовал, установил, настроил, а теперь не работает. Чья это ответственность? Селектела разве? нет, того человека, кто устанавливал и настраивал все это. А именно Сергея Осипова. Который в силу своей недалекости и слабоумия не смог адекватно, обдуманно подойи к задаче. Теперь его заказчик схватил за одно место, но вместо этого он все валит на Селектел. Мол это они, а я то чего, я простой 1Сник, с меня и взятки глатки. Ничего не напоминает?! кто тут про олдскул чего то гворил.... Типа я простой слесарь, а это кран виноват.

Серень, ты накосячил, так признай это. А то вертишься как уж на сковороде. У мобильного телефона тоже есть кучв настроек под капотом, никто не жалуется. Если не устраивает - вон купи кнопочный телефон, для пенсионеров. Ишь ты, простой 1Сник.

ближе к теме. накосячил не я, а SELECTEL (превысил объем контейнера как минимум).

вместо простого и понятного инструмента для бэкапа мы получаем какое-то устройство для гиков.

устройство для гиков выкачивания бабла.

ММмм multipart_upload, это ceph передает привет, если селектел обновит до 18 будет получше, но в целом реализовать diff между метрикой который ceph отдает по бакету и реальными объектами в бакете, несложно, но может быть ресурсно затратно, если объектов много...

Решал эту проблему с месяц назад. Тоже было не особо приятно удивлён этим косяком в UI.

Храню бэкапы gitlab, он штатно умеет в s3 отправлять их, очень удобно.

Обошёлся удалением через minio client. ansible task, может кому пригодиться заюзать:

- name: Install minio client from the internet
  ansible.builtin.apt:
    deb: https://dl.min.io/client/mc/release/linux-amd64/mcli_20240429095605.0.0_amd64.deb

- name: Set s3 alias for minio client - prepare creds
  ansible.builtin.template:
    src: ../templates/credentials.json
    dest: /root/credentials.json

- name: Set s3 alias for minio client - import creds
  ansible.builtin.command: mcli alias import selectel /root/credentials.json

- name: Clean up s3 backups
  ansible.builtin.cron:
    name: Cleanup s3multipartuploads
    minute: 0
    hour: 04
    job: mcli rm -r --force --older-than 7d selectel/gitlab-backups_s3multipartuploads/
// ../templates/credentials.json
{
  "url": "{{ s3_garbage_collector.url }}",
  "accessKey": "{{ s3_garbage_collector.aws_access_key_id }}",
  "secretKey": "{{ s3_garbage_collector.aws_secret_access_key }}",
  "api": "s3v4",
  "path": "auto"
}

не, я это не осилю.

А зря, там весь файл сводится к запуску команды mcli rm -r --force --older-than 7d selectel/gitlab-backups_s3multipartuploads/

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

mcli это уже другая утилита, не rclone?
и что делает этот замечательный код? Удаляет вообще все файлы старше 7 дней, а зачем? мне ведь надо хранить эти архивы.
Хотя если там всего 10 ежедневных архивов, конечно можно удалить файлы старше 10 дней, это как вариант, хотя бы и на том спасибо. А если бы я хранил еще ежемесячные копии, тогда бы не годилось.
Думаю Rclone тоже может удалять файлы старше определенной даты.

я выплачиваю 600 RUR в месяц

Простите, а сколько стоят ваши данные, что 600р/мес дорого для их сохранности?

а 6000 в месяц нормально или дорого? Ведь из-за обрывков объем будет расти геометрически. Я сравниваю с "горячим" яндекс-диском где за 6000 в год можно иметь 2 Тб.

а 6000 в месяц нормально или дорого

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

не соскакивайте с темы. бизнеса устраивает цена от Selectel. Еще бы качество соответствовало.

Мне кажется, что с каждым ежемесячным счетом от селектела, который превышает стоимость видимых гигабайт, надо писать отдельное обращение в роспотребнадзор, прокуратуру и другие аналогичные конторы. Вам счет на 600р, им штрафы на миллионы. И так - каждый месяц, пока не найдут нормальных разрабов и не пофиксят проблему. А потом с ответом от этих контор идти в суд, который автоматически выигрышный. Требуешь с селектела миллион за аморальные страдания. Дадут тысяч 50, все равно отобьешь ежемесячную плату. Они явно расчитывали на крупный корпорат, который такие мелочи не замечает, платит молча и которому можно втюхивать счета в 10-20 раз больше реально используемых услуг. А на мелкой компании спалились и теперь ТП остается только переходить в режим чат-бота и писать шаблонные отмазки

Западные компании рассматриваются? Hetzner Storage Box - прекрасная вещь с доступом по множеству протоколов.

Из РФ это очень геморройно оплачивать . нужно искать каких то посредников которые сделают закрывающие документы для российского юр.лица.

кстати да. Безналом не оплатишь.

За 10 лет поел я всего чего только можно c этими incomplete uploads у десятка провайдеров.
Не буду вдаваться в подробности, но иногда s3 клиенты реализованы неполно и, к примеру, не поддерживают пагинацию в запросе ListMultipartUploads или что-то подобное. А там по умолчанию выдаётся 1000 и может так оказаться, что весь клинап касается только первой тысячи.

Попробуйте запустить cleanup у rclone (как написали выше у основной корзины) раз десять и посмотрите изменилось ли существенно что-то в служебной корзине количественно (если вдруг помогло, повторите еще 90 раз). Понимаю что это выглядит немного тупо, но аналогичные действия у меня решали аналогичную проблему в примерно 20% случаев.

Небольшое PS как пример кривых реализаций:
Если серверная часть s3 хранилища это minio (не вдавался что там у селектела, но вероятно не minio, а swift) то посмотреть что там зависло нельзя: https://github.com/minio/minio/issues/13246 "We do not implement full ListMultipartUploads API on purpose. "

я думаю, удаление 20-дневных файлов поможет мне в моих цикличных архивах. Для остального S3 не годен. Но для цикличных сгодится.

Статья находится в невероятной суперпозиции - автор недосмотрел/недоизучил протокол S3, Selectel не сделал корректное лимитирование (уже который год, кстати)

не всегда ожидаешь подлянок от предсказуемого инструмента.

Так он так везде работает, инструмент этот. При этом с ним можно отлично жить, даже сайты статические на нем держу. И не утекает место, все замечательно.

HINT: лично для себя выработал правило - если беру новую технологию - то сразу ищу hacks and tips по ней. Экономит время и деньги это.

Хорошее правило.

но я не ожидал таких "детских болезней" утечки фрагментов от S3 и RCLONE. Все же есть некий ожидаемый уровень технологии.

Это как приходишь в офис, а там менеджеры в лаптях.

Привыкайте, современные облака из таких "детских болезней" и состоят.

Не усложняйте, тут мы не решаем бином ньютона, обычное копирование делаем.

Под "обычным" копированием скрывается пара десятков таких биномов, уложеных послойно.

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

Ха, черточка.
Очень даже наоборот — потому что ни в поезде, ни в подвале, ни в крупном ТЦ, ни на даче, ни еще в тысяче мест не то что скачать приложеньку в четверть гига, а даже получить sms бывает проблемно. А вы вот, похоже, не думаете в принципе — и теперь пытаетесь всем доказать, что это злобный линукс виноват в том что ненавидия перестала поддерживать семерку.
Херню порете, короче говоря.

не понял о чем вы

Это не детская болезнь, а особенности реализации. Вы же когда выбираете инструмент проверите как он будет работать? Вот и тут так же - при загрузке больших файлов есть особенность.

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

у меня нет архивов на 44 гига, 8-12 Гб максимум, размеры контейнера я не смотрел общие, т.к. был спокоен, установив лимит.

А горизонт хранения то какой? Мы вроде бы про бэкап говорим - а значит он должен быть. Должны быть оповещения при неудачном бэкапе и вот это все.

А вообще, делюсь хорошим чеклистом по хранилкам:

  1. Что мы решаем новой технологией? Что она представляет? Что есть наш файл?

  2. Какие есть плагины - сжатие, шифрование, докачка, версии? Как реализовано?

  3. Как файлы грузятся? 4, 5, 10мб, 1гб, 10, 100? А что если оборвать загрузку? Как докачать?

  4. Как это лежит у хостера? Как чистится? Что показывает биллинг?

  5. Стресс-тест хранилища. - заливает/удаляем 10000 разнокалиберных файлов

На такие тесты тратится пара суток, но в итоге все основные вопросы проверены. И вы точно увидели бы что хранится больше чем нужно.

я бы, конечно же, увидел, но у меня нет бюджета на проведение таких тестов.

Вообще, конечно, больше всего доставляет как автор сначала безопеляционно нахваливает S3 хранилище от Селектел, а потом столь же безопеляционно заявляет что вся технология S3 хранилищ никуда негодная шняга. При том что по факту он просто не удосужился разобраться как же она, эта технология, работает.

И отдельно радует это именно "холодное хранилище" везде, как будто это часть технологии S3 и "нехолодное" хранилище это уже что-то другое :)) вэ

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

Я так понимаю, холодное хранилище отличается ценой хранения.

Как ни крути, а вот этот вот накопившийся служебный скрытый мусор, о котором selectel наверное даже Не предупреждал, и сожрал деньги юзера. Такого однозначно быть не должно.

да. но они считают, что мусор - это часть сервиса. Мол это проблемы Амазона, а не их.
Типа надо чистить на стороне пользователя. Вопрос - как? нет ответа.

Для начала надо понять откуда он берётся. Но у нас облака Селектела нет, а вы никаких подробностей не сообщаете, только запутываете. Конечно же ответа "как чистить" не будет.

ну вопрос не к вам. Облако Selectel - это обычный контейнер S3

S3 - это API, а там есть вполне конкретная реализация со своими особенностями.

это вы к чему?

Нет ответа Как - раз.

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

Вывод: пахнет мошенничеством, цена ведь от объёма зависит.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории