mayton2019

Зависит от формата. В старые времена ходили трюки с JPEG. Можно было из thumbnail извлечь оригинал
картинки. Правда не в очень идеальном разрешении.

Смотрите мануал по exiftool.

Не знаю делают ли thumbnail сейчас. Это было актуально для быстрой загрузки в браузерах во время
модемного инета.

По всем прочим форматамм - надо читать документацию. Фотошопный PSD хранит много преобразований
и там шансов восстановить слои больше. Но PSD проект редко публикуется вообще.

Если тебе нужно временное место - то используй системную переменную

System.getProperty("java.io.tmpdir")

Или с префиксом и суффиксом - есть готовая функция которая возвращает файл.

Files.createTempFile("", ".tmp")

Вместо игр со счетчиком от 0 до 1000 - лучше использовать текущую дату-время или GUID.

На ум приходит идея - разделить файлы. По размеру и по роду доступа.
Например картинки - положить не в файловую систему а во внешнее хранилище типа S3.
Здесь мы исходим из предположения что размер файла будет - как средний размер фотографии в jpeg.
Потому что за более мелкими - будет дорого ходить по сети кудато.

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

XFS - хорошая система. Я все магнитные блины в нее переформатировал но не было такого опыта с мелкими.
У меня как раз очень большие файлы лежат. Датасеты.

Еще я-бы предложил посмотреть на саму прикладную задачу с точки зрения коррелированного доступа.
Например каждый пользователь читает свой index.htm, avatar.jpg, e.t.c. Имеет смысл этот сет файлов
запаковать в очень быстрый архив. По сути в пакет даже без сжатия чтобы по заказу быстро отдавать
эту пачку по сети (user_id.pack). А там уж браузер разберется. Пришлем лишнее - не страшно. Все равно пакет летит.
Главное что теперь у нас нет россыпи мелких файлов а есть среднего размера упаковки на каждого
пользователя по user_id.

Нужно делать одну таблицу и с ней работать. Самый простой вариант - обычно самый надежный и долговечный.

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

Можно short link сделать

https:// bitly.com

В чем причина повреждений - трудно узнать. Тут нужен доступ к твоему десктопу и нужно сравнивать оригинал
с поврежденной копией.

Посмотри линуксовую утилиту par2 https://man.archlinux.org/man/par2.1.en и попробуй начать ее использовать.

У меня есть архивы которым по 10-15 лет. И я их храню вместе с контрльными файлами
которые генерит par2. Она исправляет одиночные поврежденные биты на всей поверхности файла.
Насколько много или плотно - я точно не могу сказать. Тут надо ставить эксперимент. Вобщем - сам поразбирайся.

Лет 10 назад можно было на барахолках купить стриммеры HP. А кассет было много на предприятиях. Некоторые впоследствии на радиорынках продавались еще в нераспечатанном виде. Производитель лент гарантировал что-то вроде 15 лет хранения информации (при условиях правильной температуры и влажности). Это - самые длительные сроки что я видел. Размер касеты у них кажется был 20-40Гб.

Еще Verbatim продвигал какие-то особо прочные DVD+R диски с алмазным покрытием. А по объему кажется это были 4.7G Надо посмотреть я не помню точно. Вобщем надо искать + еще покупать пищущее устройство.
А сейчас даже ноуты продают уже без DVD привода.

Я у себя дома храню на двух HDD дисках серии WD-Green. Конечно непонятно что делать если от времени сгорает
контроллер но вроде как 2 сразу в один день не должны сгореть.

Идея регулируемого тарифа заложена например в AWS S3 хранилище. Там вы для старых файлов можете просто задать атрибут storage class и указать более жлобские модели хранения вплоть до ленточного архива. Но установкой атрибута класса хранения вы будете сами управлять.

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

И внешнаяя ссылка на файл вообще не должна изменяться.

Такие случаи бывали. Когда-то давно Ubuntu десктоп после обновения
плохо загружался у меня. Но с файлами при этом было все в порядке. Они лежали
на своих местах.

Если у тебя ценная информация - то надо хоть раз в неделю делать бекап на внешний
диск. Это .. как охрана труда и БЖД. Прописано кровью. Сам понимаешь. И здесь
в равной степени и Windows и Linux пострадают от сгорающего дискового контроллера
например. Еще потеря информации зависит от ошибки человека. Дрогнула рука пока мышкой
двигал. И мувнул файлы куда-то.

Для недорогих облачных хранилищ обычно используют
AWS/S3, MS-Azure BlobStorage, Google Cloud Storage.

А попробуй убери из индекса дату.

CREATE INDEX ix_imei_time ON locations (imei);

Я не работал с TimescaleDB но вообще работать со вторичными индексами в time-series - это плохая тема.
Лучше выбрать лидирующий партишен как дата. И вторичный партишен как хеш от какого-то интересующего
атрибута или группы атрибутов. И тогда оптимизатор пойдет просто в тот фасет который соотвествует нужному
пересечению партишенов.

Недостаточно информации. Обычно БД и модель таблиц затачиваются под типичный запрос.
Например. У нас есть публикации и и пользователи (те кто просматривают). Концептуально - это
матрица где по горзионтали - пользователи а по вертикали публикации. Если рассматривать во времени
то появляется третье измерение (куб) - ось времени. Где можно делать срез за последний день
или неделю или год. Каждую ось можно агрерировать (брать все данные) как бы для аналитики.

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

Работа - более экспериментальная. Делаешь симулятор запросов. И смотришь как оно работает.
Насколько быстро.

Я читернул немного и спросил всезнающий чят. Но не про утилиты самсунг а про slow down скорости для SSD. Вот ответ:

One possible reason why an SSD might slow down during copying is that it becomes busy with other operations, such as garbage collection or wear leveling. These processes are designed to help maintain the performance and lifespan of the SSD by redistributing data across the drive and freeing up space. However, they can also take up valuable resources that would otherwise be used for data transfer.

Another factor that can affect the speed of an SSD during copying is the way that the data is being written to the drive. SSDs use a technology called NAND flash memory, which allows data to be written in blocks. If the data being copied is not aligned with these blocks, it can cause the SSD to slow down or even pause during the transfer.

Для Windows/Linux.

Почти для всех браузеров когда что-то скачал и потом нажимаешь Ctrl+J то открывается фолдер
(обычно %UserProfile%/Downloads) и там лежит то что надо. Для Linux почти тоже самое /home/user/Downloads

Есть еще программный кеш для картинок, css/js/html e.t.c. Он в каждом браузере лежит по своему
маршруту но обычно где-то в %UserProfile%/.hiddenFolder и имена файлов там не информативные. Хешируются
по какой-то формуле чтоб хакеры и вирусы сами себя не нашли и не смогли передать управление.
Этот кеш пользователем напрямую не управляется но просто надо знать что он существует.
Если ты - активный сёрфер то можешь достаточно много накачать туда так чтобы создать проблемы
для свободного места. Обычно где-то в настройках есть батон для чистки этих файлов.

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

По поводу айфона - не знаю.

Там похоже дата создания файла сохраняется.

$ unzip -l -v opengl.zip  | head
Archive:  opengl.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
13049256  Stored 13049256   0% 2005-05-18 17:19 a814c96e  OpenGL/AdbeRdr602_rus.exe
      42  Stored       42   0% 2004-05-04 03:00 9dd0d91b  OpenGL/Autorun.inf
       0  Stored        0   0% 2006-02-03 18:02 00000000  OpenGL/Catalog/
       0  Stored        0   0% 2006-02-03 18:04 00000000  OpenGL/Catalog/1070801/
    4242  Stored     4242   0% 2005-12-07 16:05 c1c0e4a3  OpenGL/Catalog/1070801/index.htm
  162399  Stored   162399   0% 2005-12-07 16:09 fcb2cedb  OpenGL/Catalog/search.html

Проверь какие у тебя даты.

У автора же не сразу 50Тб а как-то постепенно накапливается?

Можно купить Blue-Ray диски на 50Гб. И писать потихоньку.
Помню еще Verbatim производила надежные диски DVD с алмазным покрытием.
Можно поискать есть ли такие для формата Blue-Ray.

SSD - точно не подойдут. Ни один производитель не гарантирует столько лет хранения информации.
С другой стороны эти же SSD стоят в облачных хранилищах где их просто спасает уровень redundancy
в 2 и 3 и более раз.

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

К слову я ничего не придумал. Немного замкнутый круг получается. Самый простой и надеждый способ - все таки использовать мнемонические фразы из стандартного bip39. Эти фразы выжечь у себя татуировкой на руке или блин заказать себе жетон на шею с гравировкой. Или как Киану Ривзу прошить в мозг под гипнозом. Вобщем нужно такое хранилище чтоб.... ну короче лучше сейфа и бумагами я пока ничего не придумал. Звучит смешно но бумага оказывается надежнее чем жесткие диски сидюки и кассеты стриммера.

Археологи подтвердят.