DATABASE met alle routes WEG!

[RedStrom]

Ik heb Basecamp op de pc en op een 2-in-1.
De database staat op een NAS. En de 2-in-1 synchroniseert met die NAS en op de 2-in-1 staat de database op een SD kaart.
Zo heb ik op beide altijd dezelfde versie en als de 2-in-1 meegaat n de tanktas werkt die ook prima.

Gister zag ik in verkenner een wijzigingsdatum van 25-5-2019 voor het alldata.gdb bestand terwijl ik toch echt dit jaar ook wel wat gedaan heb.
Dit was die op de NAS en die op de 2-in-1 was precies zo.
Synhroniseer software (Realsync) geopend en daar wat mee gedaan. En iets niet goed.
Bij het openen van van BC werden de lijstbestandgegevens bijgewerkt en die wil BC repareren. Klik op repareren, en ik zag in verkenner de bestanden en mappen in de 4.6 map verdwijnen. En 5 seconden later die op de NAS ook.
Alles van 10 jaar aan routes, tracks en waypoints weg! En nee, ik heb niet meer backups.

Geen paniek. Ze zijn vast ergens.
Gezocht op NAS, de PC en de 2-in-1. Meerdere bestanden gevonden, maar niet de oude.
Wel een map met 5100 TrackSegments. Wel nieuwe alldata.gdb, maar die zijn leeg.
Toen met Recuva, als iemand een betere weet die ook NAS kan herstellen, bestanden die weg zijn teruggehaald.
Op de NAS lukt dat niet, maar op de SD kaart wel.
Daar heb ik 1x alldata.gdb gevonden en een alldata.gdb.bak met bijbehorende folderdata.gfi.bak van dezelfde datum, van resp sep 2019 en feb 2020, en nog een map met 509 TrackSegments.

Als ik die map met 5100 TrackSegments en het alldat.gdb bestand kopieer naar de map 4.6 en BC open, zie ik meer dan 10000 items (routes, waypoints en tracks) allemaal in de map niet-vermelde gegevens.
Die zou ik opnieuw kunnen indelen in mappen en lijsten. Pffff.
Gebruik ik de 2 bak bestanden, haal .bak eraf en zet die in map 4.6, dan opent BC met het bijwerken van lijstgegevens en wil repareren. Klik op repareren en hij gooit map 4.6 weer leeg. Helemaal, alle mappen en bestanden.

Is er betere software om dat terug te halen, ook van een NAS? Partition Manager die ik heb kan het niet.
Die NAS is een WDCloud met 1 schijf. Een netwerkschijf.
Die TrackSegments zijn belangrijk, bepalend. Zijn die te laten maken in een ander programma?
Heeft het zin om uberhaupt een ander programma te gebruiken?
Moet ik van wat ik heb een gpx maken en daar iets mee doen?
Of moet ik 10000 items gaan indelen in lijsten?

Wie kan deze OEN helpen?

[RedStrom]

Nogmaals Recuva gedaan met een latere versie.
Ik zag folderdata.gfi, alldata.gdb met dezelfde datum: 8-2-2020.
Daar kopieën van gemaakt en tracksegmenten jonger dan 8-2-2020 verwijderd.
Alles in 4.6 gezet, BC opgestart, en wederom reparatie nodig van die lijstbestanden en weg zijn de bestanden.
BC is nu al een half uur lijsten aan het herstellen, volgens het kadertje tenminste, niet volgens de processoractiviteit.
Maar ik laat het maar even lopen. Wie weet.

Ik heb het idee dat ik wel goede bestanden heb, maar hoe knoop ik ze aan elkaar?
Moet ik wel .bak bestanden gebruiken?

Ik heb 1 versie alldata van 76 Mb met die met diezelfde TrackSegmenten die met de de andere bestanden van 1 Kb, dus alle dat laat zien maar in 1 bestand.
Weet iemand hoe ik die weer in mappen en lijsten kan krijgen, en dan niet handmatig? 10352 items.

[RedStrom]

JaVaWa, kun jij hier wat mee?

[JaVaWa]

Nee, helaas niet...

Behalve dan adviezen geven waar je nu waarschijnlijk niet op zit te wachten...
Een NAS is geen goed backupmedium; een NAS moet je óók backuppen. Synchroniseren is leuk, maar je hebt geen versiebeheer en (onbedoelde) fouten worden ook meegesynchroniseerd.

[RedStrom]

Dank je in ieder geval voor je reactie.
Backup en syncen is inmiddels anders ingericht. Het ging wel 10 jaar goed.

Ik had gehoopt dat je iets meer wist over de bestanden en mappen in de 4.6 map en hoe die onderling samenwerken en wat de voorwaarden zijn omdat te laten werken. Misschien had ik dan iets gekund met de data die ik heb.
Het luister nauw welke alldata.gdb, folderdata.gfi en tracksegments je bij elkaar zet.
Is dat niet goed dan wil BC repareren en dan gooit hij schijnbaar de bestanden weg, niet de mappen.
Ik zeg schijnbaar omdat ze niet naar de prullenbak gaan. Maf verschijnsel. Ik heb ook niet het idee dat die bestanden op de achtergrond hersteld worden. Dat zal toch geen uur duren op een I7.

Helaas. Ik zal de 10000 itmes die ik heb opnieuw indelen. Veel zullen er verdwijnen.
Ik hoop wel mijn buitenlandse ritten goed te krijgen. Vakanties en zo.
Een paar motormaatjes kunnen daarbij vast helpen. Uiteindelijk komt het wel weer goed

[JaVaWa]

Het luistert inderdaad nauw.

AllData.gdb is een binair bestand, het komt sterk overeen met het oude gdb-formaat dat je in MapSource gebruikte (maar is niet helemaal hetzelfde en kan daarom niet door MapSource ingelezen worden). Het bevat waypoints, routes en tracks.
Het gdb-formaat ondersteunt bij tracks echter maar een paar kenmerken, dingen als hartslag, cadans etc. niet. Daarom hebben ze bedacht alle kenmerken van tracks op een andere manier op te slaan, en dat zijn de bestanden die in "TrackSegments" staan (gooi je die weg dan heb je nog steeds de track zelf, alleen zonder extra kenmerken).

Het gdb-bestand kent geen mappenstructuur, dus daar hebben ze een ander (binair) bestand voor bedacht: FolderData.gfi. Daarin wordt bijgehouden welke mappen er zijn en welke waypoints, routes en/of tracks daarin staan.

Die bestanden horen allemaal bij elkaar, en als ze niet overeenkomen zul je dus bepaalde data verliezen. De gdb is wel het belangrijkste bestand.

De structuur van de oude gdb-bestanden is door slimme mensen ontrafeld, en daar heb ik dankbaar gebruik gemaakt bij het maken van mijn software. In de MapSource-tijd is het gdb-formaat nauwelijks gewijzigd en wordt nog steeds gebruikt bij het im- en exporteren in BaseCamp. De structuur van AllData.gdb werd echter wel steeds gewijzigd, bij elke update werd het aangepast. Daardoor weet alleen Garmin hoe de opbouw van het bestand precies is.

[RedStrom]

Aha. Dit is uitleg waar ik iets aan heb.
Als ik de juiste folderdat.gfi en alldata.gdb heb dan ben ik er?
Ik hoef geen tracksegment te hebben, die map mag leeg zijn?
En de 2 bak bestanden komen vanzelf wel weer.

Weet je wat BC oet als er een lijstbestanden reparatie gedaan wordt?
Want dan gaat het mis. Ergens match er data niet en dan gooit ie het weg.

Edit:
Ik heb een gdb en gfi van dezelfde datum bij elkaar gezet en tracksegments leeg gemaakt. Maar helaas.
BC wil weer de lijstweergavebestand repareren en gooit heel map 4.6 weg.

[JaVaWa]

Als ik de juiste folderdat.gfi en alldata.gdb heb dan ben ik er?

Dat zou voldoende moeten zijn, maar wel van dezelfde datum èn dezelfde tijd.

Ik hoef geen tracksegment te hebben, die map mag leeg zijn?

Ja

En de 2 bak bestanden komen vanzelf wel weer.

Klopt

Weet je wat BC oet als er een lijstbestanden reparatie gedaan wordt?

Geen idee...

[RedStrom]

Tracksegment leeg, geen bak-bestanden werkt inderdaad.
Ik heb een bak van een gfi en een gdb van dezelfde datum en tijd. Teruggevonden met Recuva op de SD van de 2-in-1.
Die .bak heb ik weggehaald en zoals hierboven bij elkaar gezet.
Dat ging toch fout.

Ik heb net die gfi en mijn gdb waar ik wel bij kan bij elkaar gezet.
Wederom wil BC dan repareren, maar nu gooit ie alleen dat gfi bestand weg en niet meer de hele map 4.6.
Bij het afsluiten maakt hij zelf een gfi en dan werkt het weer (met alles in 1).
Opmerkelijk verschil. De ene keer wordt alles weggegooid en de andere keer alleen de gfi.

[JaVaWa]

Zet Recuva bestanden alleen terug als ze voor 100% hersteld kunnen worden, of kan het voorkomen de het resultaat niet helemaal exact wordt teruggezet? Er hoeft maar een heel klein stukje overschreven te zijn om het bestand onbruikbaar te maken.

[RedStrom]

Er staat uitstekend achter in Recuva.

Even nog die tracksegments. Waarom heb ik 5000 van die dingen?
Ik heb behalve een Zumo geen andere data die ik opsla.
En voor deze herstelactie kan ik ze rustig weglaten, en hoef ze via Recuva niet te recoveren?

[JaVaWa]

Da's niks, ik heb er tienduizenden... Er zijn er een hoop meer van dan het aantal tracks dat je hebt.
Op de Mac kan ik ze rustig weglaten, op Windows heb ik het niet getest.

[RedStrom]

Op de 2-in-1 alle combinaties van gdb en gfi geprobeerd. Geen enkel resultaat.
Nog 1 kans. En dat is bestanden terughalen op de NAS. Recuva kan dat niet.
Voordat ik op de NAS hetzelfde ga doen en allerlei sporen ga wegwerken moet ik op zoek naar een programma die kan wat Recuva kan maar dan op een NAS.
Help!

[keesm]

Voorop gesteld dat ik geen recovery/NAS deskundige ben, kwam wel deze info tegen:
Recuva is capable of recovering from NAS devices, however the drive needs to be connected directly to the machine via USB/IDE/SATA. Recuva is not capable of recovering data over a network.
Proberen waard lijkt me.

[RedStrom]

Werkt als je een USB aansluiting hebt.
En die heb ik niet.
Een schijfletter geven werkt ook niet.
Ben nu diverse software aan het proberen.