Zumo User Forums

I've been fiddling unsuccessfully, trying to recover some of the numbered archive files in "internal storage / GPX / Archive" that got auto-deleted at the 20 file cap before I got around to grabbing them. Not for any critical reason, just a little OCD trying to complete the logs of my journeys.

Has anyone succeeded?

Here's my failures so far for posterity in case they help anyone. I have a Win 11 PC. I have used Recuva and other utilities in the past to get back deleted files. The trick here seems to be that the zumo OS is Android.

1) I set the zumo to show system files (via the Configuration Menu behind a long press of the trip data page top center speedo) but the deleted files weren't just hidden. Nothing new there. Not that easy.

2) Tried to use Recuva. But I can't get the zumo to the point where I can assign it a drive letter under the PC's Drive Management too. I tried both MTP and the USB Ethernet modes but it's a no go. Without a drive letter, neither Recuva nor Disk Drill will work on the disk volume.

I did find the key safety tip if you are trying to use USB Ethernet mode, you need to have the device ON when you connect the cable or it will never get recognized. I haven't been any more or less successful in Auto MTP or USB Ethernet mode, though device recognition is certainly quicker in Auto MTP mode.

The interwebs are in discord over whether anything is possible with Android, but the most firm "this will do it" statement was to use Disk Drill on a Mac. That might be my next step when I can, but I'm Mac-less.

I don't know how the storage space is allocated, but keep in mind that the number of Active Logs is limited, with the oldest file being deleted as a new one is started. Your old files may have simply been overwritten.

lkraus wrote: Fri Aug 22, 2025 10:05 pm I don't know how the storage space is allocated, but keep in mind that the number of Active Logs is limited, with the oldest file being deleted as a new one is started. Your old files may have simply been overwritten.

Table stakes for the question was already well past that.

My old files have certainly been deleted. Which is not the same as over-written.

BigBird wrote: Fri Aug 22, 2025 10:00 pm 2) Tried to use Recuva. But I can't get the zumo to the point where I can assign it a drive letter under the PC's Drive Management too. I tried both MTP and the USB Ethernet modes but it's a no go. Without a drive letter, neither Recuva nor Disk Drill will work on the disk volume.

The drive letter issue was the first thing that came to my mind after reading the first paragraph of the original post. I am not aware of any recovery tool that will work when you can't mount a volume and assign it a drive letter. That is in my Windows world though. The MAC is a different different animal. Good luck wrestling it.

I use Open MTP on my iMac to read XT files and it will not recover deleted ones. However, searching for a solution, I came across this, which offers Mac or Windows versions:

https://download.ibeesoft.com/iBeesoft- ... covery.exe

-dan

I gave iBeesoft a try, @danham. Same result. The zumo device doesn't register as a location that can be scanned. It may be a great finisher, but I can't start it. Thanks for looking.

@Peobody, yup, I think drive letter is the root of the matter. There are a couple of third party tools for doing that for an Android device, but glancing two lines deep at the details they require either an install on the device or setting it to USB debugging mode which isn't available in the zumo's closed OS. There are some other esoteric drive-making ideas mentioned in passing but I don't understand them and I think finding a Mac to try Disk Drill there may be easier than a PC science project.

Or maybe I'll just up my meds and not bother with the old archive files.

I had a surge of good riding this summer and blasted through 20 archive files faster than usual.

BigBird wrote: Sat Aug 23, 2025 11:55 am I had a surge of good riding this summer and blasted through 20 archive files faster than usual.

The earlier Zumos would have 20 miles and each one would store approximately 1 and 3 Mb approx. How long this lasts is determined by how much riding you do. I used to back mine up every three months. So I'd do it before we went on tour, but that was plenty for 20 days 3,000 miles while were away.

Just to backup what has already been said. Even if you could get at the files, the 1st entry is removed before the 21st is written. 'Removed' means that the entry in the index is 'tippexed out' . The blocks of data used by the file are marked as available. If you get in there quickly you can sometimes recover file intact. The probelm is that you have a large file (the 21st) looking for somewhere to be saved. And - Oooh look - here a tippexed out entry right at the top of the list. And then it goes looking for where it can store the data. The Zumo will choose blocks of data apparently at random and each block will have a pointer to where the next block is saved. A large file like that will occupy many blocks. In order to recover one, you need to know where it starts. And that is saved with the index entry.

But you are right - if your Zumo was using Mass Storage Protocol, rather then Media Transfer Protocol, you would have a drive letter and that can be seen by data recovery software. So I though that I would give it a go.

The screen shot (click on it to see it in original size) is of Drive G: - An attached Garmin Zumo 590, which I bought second hand off the internet cheap. It had dodgy case - but that was OK - I was replacing the circuit board. I've never taken it out since I bought it a few years ago - it has only been used as a desktop aid for reference. It is set to use Mass Storage - becasue that is the only way tthat you can make the .System drive visible on the 590/595s.

So my Disk Management Software (PrivateDisk) can read all fo the file names of valid and deleted files and it can make a good stab at recovering the data from the disk drive - if it has not been over-written.

All of the red entries are deleted files. The black ones are current. They are dated April 2024. They are mine and contain only the tracks that have been recorded while at my desk ! I'm surprised that it has used up to number 5.

The deleted ones are from May to Sept 2022. The 1st Cluster column at the right hand side - some of them are in brackets, which means that the first cluster has been overwritten. 3 are not overwritten, so I asked the software to recover the files.

What I got was gobbledegook. The first cluster may not have been over-written, but it must be pointing to the second cluster which definitely has been overwritten. And that is just from me turning the Zumo on and off without any further tracks being recorded.

So it looks like even if you managed to get access to the drives, they are not going to give up a great deal of information.

Lesson learned. If you want to keep the files, Keep an eye on the file numbers.
If you ever reset your Zumo to factory, then all of these are cleared out and your Archive folder starts from zero again.

I never got to grips with how the XT1 stores its files. It would occasionally miss a number and there was some evidence that more recently archived files were being updates after being archived. I started copying everything into a folder - including CurrentTrack Log and also any files that I had already archived. If it asked to overwrite, then I allowed it. That way I had the most up to date versions. If I had carried out a complete system reset, then I started a new folder to keep the new archives in and dated the old folder. Eg "TrackLogs up to 23 Aug 2025"
The XT2 certainly does this. My understanding of what went on with the XT1 was not clear - but I assume that it was an early version of what the XT2 does. The XT2 doesn't overwrite archive files that are younger than 6 months.

The XT has a much larger drive than the 590 so the likelihood of any given cluster with a deleted file relic being over-written is smaller. But, yes, the sooner the better for file recovery, in general.

Like you, I tend to pull my archives every few months. But I had a real good few months and lost a half dozen files.

BTW, always re-pull the last one or two that you've got. Like recently when my local backup stash was up to 141 and the device was up 152, I pulled 141-162. Because the last time I copied 141 it was only half full, and gets written to incrementally. If I had pulled 142-152, I would have missed the second half of 141.