• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [Verizon] 100% backed up?

RBEmerson said:
Sigh... I was afraid of that. The problem with FAT, FAT32, and exFAT is the File Allocation Table has to be re-written too often. Copying 37G from the present SD to a 128G microSD takes... you don't want to know. And if the target SD is toast... it's not pretty. :mad:
Click to expand...

For that kind of heavy-hitting file copy, I would power down the phone, pull the card, and use my PC - ideally with a USB 3.0 SD adapter, if possible, to copy the files to a hard drive, then to a new SD card, if that's your intention.
 
NSDroid said:
@Zoandroid, i was just looking at a few things on the S5 and apparently my "camera" pix are automatically saved to my extsdcard (can't figure out how that got setup bc I don't see anyway to change the dir path). However, "studio" gets created on the phone itself and I don't see how to modify where that gets saved. So I guess what may have happened is everything that wasn't part of the "camera" area/folder, got erased and when I restored from the TIBU backup the only pix i had were still on the extsdcard. I assume the pix that were part of the "phone" itself were never part of the backup of TIBU??
Click to expand...

Probably not. The only way I can see that pics might possibly get backed up using TIBU might be if for some reason they are seen by TIBU as "application data" files which might then be copied along with the camera app that took the photos? But that is a very long shot in the dark, and I wouldn't expect to see it happen.

I would love to see every app and hardware utility (like the camera) fully user configurable when it comes to where files are stored. But that is a tall order! In the real world, we are at the mercy of pencil pushers and programmers who presume too much about how their apps will be used. The only way to know which utility and app has such settings is to dig for them one at a time. We are never told this in any user manual. ;)
 
OK, I decided to investigate how to specify where the S5 camera stores its pictures. Somehow my S5 has pictures stored in BOTH the internal memory and the SD card, and I know I took all those pictures with the S5. When I could not find a setting either, I Googled it.

In the Camera Settings menu there is supposed to be a Storage icon. I did not see one in the 4 rows of 4 icons that fill just over half my display in portrait mode. Note there is a large BLANK area under them!

Well of you look very carefully, you should see a pale gray thin line to the right of the first two and a half rows of setting icons (with all that BLANK SPACE beneath them.....room for 2 MORE rows of icons.....it is a scroll bar indicator.

Here's the big hidden secret.....touch the 4 rows you can see, and drag upward! Viola! 3 MORE rows of setting icons. Which, had the designers been more than chimps, could easily have been made to ALL fit on the display! But......they chose to spoon feed us through a tiny window portion of this spacious display, and of course not TELL us that there are 3 HIDDEN rows of settings. Instead, they pop up a blue message telling us we can tap and hold and reorganize them.

One of my very major pet peeves is to be forced to use some aperture smaller than what the device can display, just because of some programmer's stupid idea. Like Windows that are tiny and can't resize, to access something that makes you scroll to see it all.

So, mystery solved. The Storage setting, once you find it, is where the photo storage location is set. :)
 
Zoandroid said:
For that kind of heavy-hitting file copy, I would power down the phone, pull the card, and use my PC - ideally with a USB 3.0 SD adapter, if possible, to copy the files to a hard drive, then to a new SD card, if that's your intention.
Click to expand...

BTDT with exFAT. IIRC, it took almost a day to move 37G. The source was in a microSD to SD adapter, and the target (128G) was in a USB multi-card adapter plugged into a USB 3.0 port. The problem is, as I said above, after adding a (small) amount of data, the File Allocation Table has to be re-written. Do that with 17000+ files and the FAT is re-written a lot. NTFS doesn't have this issue but, AFAIK, the S5 doesn't grok NTFS.

I tried using Acronis to do a partition image copy from the source (64G) SD to the target SD (128G). The resulting SD was unreadable under Win7, Linux, or the S5. Now, it may be the 128G is defective. Some tests think it's OK, some don't. I have a new 128G SD on order.
 
Hmmmm... good question - thanks for finding the app. I'll have to stare at this a bit. Meanwhile, I'm trying at another Acronis image restore. Call me a masochist... :D
 
RBEmerson said:
Hmmmm... good question - thanks for finding the app. I'll have to stare at this a bit. Meanwhile, I'm trying at another Acronis image restore. Call me a masochist... :D
Click to expand...

You're welcome. Maybe you can put it to use. Googling How to use NTFS with Android KitKat yields some rather geeky dialog between some folks who it appears have made it work, but they had to take certain programming steps to help it along. Outta my league. :)
 
You're seeing the general trend I found. If I have to whack the phone hard to get it to see NTFS, not so good. Worse, I think the general discussion is aimed more towards supporting HDD's tied to phones and tablets. Not quite the internal microSD I have.

Acronis is still flailing away at writing the image, which probably means once again I'll get a lot of nothing I can access. Feh.
 
Back in the 90s I was a big fan of Drive Image for Windows. Once Symantec bought and killed it off I've tried several other partition imaging utilites, but never found one I liked. The System Restore feature of Windows has also proven unreliable for me, more often saying it can't restore than actually being useful. My sister has similar issues with it.

So over the years I have decided simply copying the files in their native state is the most reliable way to back them up. Especially with optical media and burner drives getting very affordable. Including backing up Android devices.

But the bottleneck here for you seems to be USB itself, which I've never liked from its onset. I keep waiting for something truly remarkable to take its place. Its been a long, dry wait.....

I wonder if there is such a critter as an SD card reader that uses eSATA instead of USB to transfer the files?
 
There's no question that SD's (micro or not) are awkward to live with somewhere past 32G. Couple that with having to live with a FAT-based file system, and even a USB 3.0 device isn't going to speed things up by much. It's that pesky need to continually re-write the file allocation table, when it's for a "many G" device, that makes things move at "molasses in January" speeds; big tables, big delays. I doubt a SATA device would speed things up enough to warrant the expense.

I started this image recovery Sunday evening around 9:30PM. At the moment it's 5:30PM on Monday. The job says it's 80% complete. [/face palm]

BTW, the work is being done on a Samsung serious kick-butt gaming machine. Processor horsepower, free RAM, fast drives? No worries, mate!

- - - -

BTW, the "rewriting the FAT" thing is precisely what slows up a "copy file by file" transfer. There is one small hope. Under Win7, open the control panel, go to Administrative Tools, choose Computer Management, and then double-click on Disk Management. In the section with the digrams of disk partitions, right click on a removable drive's description (not on the diagram!) and choose properties. Look for the Policies tab and open it. There's an option to use a write cache for the device. Go with that and it will usually speed things up. If the copy app you're using doesn't make direct, very low level device calls. Do things at the OS level, and the caching will speed up SD's and USB sticks.
 
Wow RB, that operation would be completely unacceptable to me! No wonder you're so frustrated. I have not moved above 32GB SD cards in capacity. I've thought about it, but after learning all this I may never use them. Taking that long to copy something is far beyond laughable.

I really don't need more than 32GB at the moment. I'm only using about half of it on my S5, leaving lots of room for the piggish nandroids Safestrap makes. Even with compression turned on my latest stock ROM nandroid with the system and data selected was 3.2GB

But I usually don't carry around more than one or 2 of the latest nandroids for emergency restoration.

You are copying from one SD card over to another? Would it be any quicker to copy to a hard drive first, and then back to an SD? Maybe if you used an SSD as the middle man?
 
The SD -> backup image takes ...[/shrug]... under an hour. It's laying the image back onto the new SD that takes so long. What's really bothersome here is Acronis shouldn't really care about the content - it's just taking an image of a partition and slapping it onto another device.

If any Linux I can get my hands on understood exFAT, I'd use rsync to do the transfer. I've done much larger transfers between HDD's and they don't take anywhere near this long. But then, they don't use exFAT, either.

BTW, 23h 30m later, Acronis reports being 90% done and needing another 4 hours to wrap up the job. I'll believe it when I see it.

BTW, I another backup app, Areca, to do a file by file transfer. It created the entire folder structure but failed to populate some of the folders. Which is why I'm not 100% sure this SD is healthy. It's a cheapo SD and I ordered another just to see what happens. I think I mentioned earlier I have a predilection for masochism? ;)
 
Yea, ya did. lol :)

I don't recall if I mentioned that I used to encounter failed file transfers that I finally pinned down to 2 folders on my Galaxy S III, both of which were in the /Phone segment of its memory. One folder was Evernote, and the other was named Android.

In each case, the path name to some of the files was ridiculously long. Like over 300 characters. It caused Windows 7 to choke and give up, simply stopping the file copy as if it had completed successfully. I stopped backing up those 2 folders, and things have worked very well ever since. I wonder if anything similar is hampering your efforts on the PC?

Ever heard of a Windows program called "BRU" (Bulk Rename Utility)? That's what I use to examine path names and shorten them when necessary so I can write an entire partition's files to a disc. Nero will sometimes puke when path names are too long, and fail to burn a disc.
 
Unfortunately, the failure is easy to spot. Much of the old (64G) SD is filled with MP3's. I watched TeraCopy move copies of an album from the old to new SD. And then the checksum would fail. The files were truncated. This applied to JPG's and other stuff, too. Which is part of why I have my doubts about the 128G SD.
 
@Zoandroid, so ever since I backed up using the above method I've noticed a significant battery drain. One thing I did in the last few days was moved all the apps I cld to the extsdcard so I'm not sure if that is causing my battery to drain quicker or whether it was doing the whole Safe strap and stock rom backup part. I was thinking of going back to the point where I restore the nandroid backup I made last week but not sure how to do that exactly. Can you kindly guide me if you know how?
 
NSDroid said:
@Zoandroid, so ever since I backed up using the above method I've noticed a significant battery drain. One thing I did in the last few days was moved all the apps I cld to the extsdcard so I'm not sure if that is causing my battery to drain quicker or whether it was doing the whole Safe strap and stock rom backup part. I was thinking of going back to the point where I restore the nandroid backup I made last week but not sure how to do that exactly. Can you kindly guide me if you know how?
Click to expand...

In the clone of TWRP recovery you see when you boot to Recovery from SafeStrap, in the right hand column of "buttons" the 2nd one down is Restore. Tap that, and at the top of the screen under the Battery % listing will show "Storage:" and it should show "Micro SDcard" with some value of free storage on your SD card listed in parentheses. If it doesn't show that, and shows Internal Storage, then tap on it and select Micro SDcard, then tap OK at the bottom to get back to the Restore screen. This, assuming you did make your nandroid backup(s) to the real SD Card.

On this Restore screen you should see folder icons followed by the names of every nandroid backup you have made to your SD card. Tap the one you want to restore. The next screen lets you opt to restore any or all of the selections you made at the time of backup. For me, that shows both Data and System. You want them both if you are wanting to take your phone "back in time" to that backup file point.

With your selections checked (both, as mentioned above) at the bottom is a Swipe to Restore sliding button control. Swipe that to the right.

You'll see status messages on the screen and probably a progress bar. (I say probably as genuine TWRP has one, but I have never restored a SafeStrap backup nandroid yet, so I can't be certain). It will take some time, so let it finish. When complete it will show you a Reboot button. Tap that and reboot back to the System (not back to Recovery), and you should see things just as you had them before you made the backup. All your apps, settings, everything. Neat, isn't it? This, and TIBU are THE reasons I started rooting Android devices.

Yes, I've used some custom ROMS on devices, but if there were no custom ROMs I would still root just for these 2 abilities.

One more thing. You might want to verify in the Advanced/Settings/Screen that the silly power saving feature is either gone (it seems to have mercifully been removed from SafeStrap 3.75's 'TWRP v2.7.1.0' version) or is turned OFF if it shows up in whatever version you have. If it is on, it shuts off the display every few seconds, making you think the phone has died during these critical recovery operations. I am SO glad to see it has been removed from the version I have!
 
RBEmerson said:
Unfortunately, the failure is easy to spot. Much of the old (64G) SD is filled with MP3's. I watched TeraCopy move copies of an album from the old to new SD. And then the checksum would fail. The files were truncated. This applied to JPG's and other stuff, too. Which is part of why I have my doubts about the 128G SD.
Click to expand...

As much as I'd hate to see you lose files, it seems there may be a chance some of them, of the 64GB card itself, is corrupt. That might explain all the lengthy attempts to copy the files.
 
The 64G SD's pretty solid. The delay's all on the 128G's side. And that makes sense with FAT-type file systems. The table gets pretty ugly big, even with 64K sectors (forced because of the device size). And 64K sectors are not very good for space management. (Remember that reading a FAT device incurs no "gotta re-write the FAT" penalty, only adding data does that)

All in all, more and more, I think 128G is simply a bridge too far. What really fries my bacon, though, is Titanium's seeming inability to create an external backup.

Think about it. How weird is a backup system that demands the backup appear on the device being backed up. Lose the device and the backup goes, too. [/face palm]
 
RBEmerson said:
The 64G SD's pretty solid. The delay's all on the 128G's side. And that makes sense with FAT-type file systems. The table gets pretty ugly big, even with 64K sectors (forced because of the device size). And 64K sectors are not very good for space management. (Remember that reading a FAT device incurs no "gotta re-write the FAT" penalty, only adding data does that)

All in all, more and more, I think 128G is simply a bridge too far. What really fries my bacon, though, is Titanium's seeming inability to create an external backup.

Think about it. How weird is a backup system that demands the backup appear on the device being backed up. Lose the device and the backup goes, too. [/face palm]
Click to expand...

Isn't the REAL SD Card considered an external device?
 
Strictly speaking it is. But lose the phone, lose the backup. So, practically speaking, it's internal, at least as applies to backups. Which is why I keep looking for a good way to back up the phone elsewhere.

In addition to the absurdity of storing a backup on the backed up device, keep in mind that device has to leave room for the backup. I've got 37G on a 64G SD. Oops... no room for a backup.
 
RBEmerson said:
Strictly speaking it is. But lose the phone, lose the backup. So, practically speaking, it's internal, at least as applies to backups. Which is why I keep looking for a good way to back up the phone elsewhere.

In addition to the absurdity of storing a backup on the backed up device, keep in mind that device has to leave room for the backup. I've got 37G on a 64G SD. Oops... no room for a backup.
Click to expand...

Well, now you're touching on why I like to back up my SD card once a week. :) There are a ton of people who never technically "back up" their hard drives in their computers to some other media, and I've certainly replaced my share of sudden death hard drives (and SD cards).

It's a shame you can't get that 64GB SD card to copy reasonably quickly to your PC. As I keep saying, I guess we need a new interface to replace USB, which IMO, has never been what it was stated to be when developed.

Maybe its time to develop fiber optic SD cards, and the infrastructure to transfer their data.

Or, there is always "the cloud". lol Talk about mindless trust. :)
 
The more I play with the 128G, the more I think it really is broken. I can load up everything but the MP3's and the copy process validates. Try to copy the MP3's and the data moves but it's corrupt and flunks checksum tests. After that, even if I copy known good files on the 128G, those copies tank, too. I've tried different adapters, different sources for the MP3's, and none of it works. Something's borken.

The 64G, however, continues as it should.
 
RBEmerson said:
The more I play with the 128G, the more I think it really is broken. I can load up everything but the MP3's and the copy process validates. Try to copy the MP3's and the data moves but it's corrupt and flunks checksum tests. After that, even if I copy known good files on the 128G, those copies tank, too. I've tried different adapters, different sources for the MP3's, and none of it works. Something's borken.

The 64G, however, continues as it should.
Click to expand...

It does sound as if the 128GB card has issues. What brand is it, and what class?
 
Well, well, well... It doesn't seem to be the SD after all. I've been using a Win7 copy utility called TeraCopy. It's supposed to be quicker and verifies its copies. As soon as, in frustration, I tried a straightforward copy... it all works. The MP3's play, the JPG's show up, etc., happy etc. In short, I seem to have found a way to break TeraCopy.

So... Acronis is ultimately unable to do a simple image restore, TeraCopy panics at some point, and I've been chasing my tail all over the known universe for nothing. But consider me happy anyway.
 
RBEmerson said:
Well, well, well... It doesn't seem to be the SD after all. I've been using a Win7 copy utility called TeraCopy. It's supposed to be quicker and verifies its copies. As soon as, in frustration, I tried a straightforward copy... it all works. The MP3's play, the JPG's show up, etc., happy etc. In short, I seem to have found a way to break TeraCopy.

So... Acronis is ultimately unable to do a simple image restore, TeraCopy panics at some point, and I've been chasing my tail all over the known universe for nothing. But consider me happy anyway.
Click to expand...

"Don't ya just love it!?"

I'm glad you found a solution. I suppose this speaks yet again to why I generally don't like PC backup programs. One would think it a simple concept really.......take file A and copy it over to here.....rinse and repeat. Even lowly DOS could do that decades ago. Makes ya wonder why today's "sophisticated" application can't do something that simple, doesn't it? Sometimes I think all the stuff they toss into todays computer programs is just to confound us and make life more complicated.

Oh, wait. That's Linux. lol :p
 
You must log in or register to reply here.
Back
Top Bottom