Восстановить информацию из бэкапа.

7 posts / 0 new
Last post
Pulemet

Здравствуйте!

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

Каким образом информацию из файлов *.bak перенести в программу, чтобы история снова присутствовала в лентах?

Funcy-dcm
Путь к каталогу бэкапа и путь

Путь к каталогу бэкапа и путь к файлу базы данных можно посмотреть здесь: "Помощь->О программе->Информация".

Необходимо файл бэкапа (типа: feeds.db_0.xx.x_2014-xx-xx_xx-xx-xx.bak) скопировать в каталог, где расположена база дынных (feeds.db) и переименовать файл бэкапа в feeds.db.

Pulemet
Спасибо!

Спасибо!

AV
Здравствуйте!

Здравствуйте!

У меня есть несколько копий бекапа feed.db_xxx.bak и ни из одной не могу восстановится.

Я портативную версию поместил в облако. И вчера слишком часто запускал QuiteRSS на разных компьютерах.

Еще есть:

 1. несколько файлов типа feeds (PC-name conflicted copy 2015-06-26 17 31 49).db

 2.несколько файлов типа QuiteRss (PC-name conflicted copy 2015-06-29 13 10 12).ini

 2. несколько файлов типа debug (PC-name conflicted copy 2015-06-28 09 38 24).log

Настройки QuiteRss.ini восстановить удалось. А вот все ленты feeds.db ничего не нахожу.

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

AV
Ух! Надежда не умирает если

Ух! Надежда не умирает если бьешься до конца! Всё же удалось восстановится!

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

Имеем файлы:

feeds (PC-name1 conflicted copy 2015-06-26 17 31 49).db

QuiteRss (PC-name1 conflicted copy 2015-06-29 13 10 12).ini

feeds (PC-name2 conflicted copy 2015-06-26 17 31 49).db

QuiteRss (PC-name2 conflicted copy 2015-06-29 13 10 12).ini

Вот пара этих файлов может быть рабочим набором.

Берем делаем копию папки QuiteRSS для проб и ошибок.

Берем пару файлов посвежее и делаем из них:

feeds.db

QuiteRss.ini

Я делал сначала feeds.db

Запускал. Ленты с собщениями появились, но в таблице сообщений вместо их названий были совершенно посторонние столбцы. Только после добавления парного QuiteRss.ini появились названия сообщений в нормальном виде.

Однако при повторной успешной попытке восстановится парных по времени feeds.db и QuiteRss.ini не было. QuiteRss.ini пришлось потом перебирать из имеющихся копий и с 3-й попытки нашелся нужный.

Еще момент

Имеем файлы:

feeds (PC-name1 conflicted copy 2015-06-26 17 31 49).db

QuiteRss (PC-name1 conflicted copy 2015-06-29 13 10 12).ini

feeds (PC-name2 conflicted copy 2015-06-26 17 31 49).db

QuiteRss (PC-name2 conflicted copy 2015-06-29 13 10 12).ini

Описанную выше процедуру проводим на компе PC-name1 с файлами:

feeds (PC-name1 conflicted copy 2015-06-26 17 31 49).db

QuiteRss (PC-name1 conflicted copy 2015-06-29 13 10 12).ini

Но при повторной успешной попытке имя компьютера PC-name1 не совпадало с именами файлов резервных копий.

Мало того feeds.db и QuiteRss.ini были от разных компьютеров. Когда подошел feeds.db просто подбором подошел QuiteRss.ini.

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

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

Осталось выбрать пару feeds.db и QuiteRss.ini, которые давали более свежие данные. И на всякий случай я переписал из в чистую копию портативного QuiteRSS.

Успехов!

 

 

Funcy-dcm
Интересно в чём могла быть

Интересно в чём могла быть причина поломки файлов

AV
Портативная версия

Портативная версия установлена в облаке. Облако имеет синхронизированные локальные копии на каждом компьютере. Выхожу из QuiteRSS. Он там какое-то время сохраняет свою БД. После этого Облако синхронизирует онлайн версию с локальной. На это тоже идет время.

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

Накануне перед поломкой файлов я активно "скакал" между компьютерами. Скорее всего это и стало причиной.