DroidForums.net | Android Forum & News
This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!
Proper Backup/Restore For New Droid
- Thread starter billyidle
- Start date
Proper backup
I like you just had to get a new droid.
Although Verizon tech support claimed that the settings would come back. They didn't.
Under settings privacy there is a setting called "Back up my settings", but if it does do backups, it doesn't seem to have a restore feature.
It sure would have been nice to not have to set up applications, widgets and shortcuts.
No one can dispute the droid is a computer. Who makes a computer without a backup/restore?
Misfit
I like you just had to get a new droid.
Although Verizon tech support claimed that the settings would come back. They didn't.
Under settings privacy there is a setting called "Back up my settings", but if it does do backups, it doesn't seem to have a restore feature.
It sure would have been nice to not have to set up applications, widgets and shortcuts.
No one can dispute the droid is a computer. Who makes a computer without a backup/restore?
Misfit
It will set up like your current one in regards to apps and contacts. You may have to manually store some of the free apps but they will be in your downloads in the Market so you won't have to look up each individual app.
Now as far as other settings goes, those you will probably have to do over yourself again.
That's just it. The Droid is not a computer, it's still just a smart phone. Unfortunately people have expectations that it's like a computer and that simply isn't true.I like you just had to get a new droid.
Although Verizon tech support claimed that the settings would come back. They didn't.
Under settings privacy there is a setting called "Back up my settings", but if it does do backups, it doesn't seem to have a restore feature.
It sure would have been nice to not have to set up applications, widgets and shortcuts.
No one can dispute the droid is a computer. Who makes a computer without a backup/restore?
Misfit
I have tried to ask this question too.
Blackberrys have the ability to backup all settings so when i load new OS's onto them they bounce back and nothing appears changed.
The fact that Android uses cooked ROM's and has to be flashed like WinMo is what i have deduced to be the problem.
Because it's an entire new image vs OS composed of pieces like BB, the system settings aren't aware of where anything is located and cannot restore said system settings.
Am i correct? That's my guess.
Also, someone tell me what the -o is in "mount -o" ......driving me nuts. :icon_eek:
Blackberrys have the ability to backup all settings so when i load new OS's onto them they bounce back and nothing appears changed.
The fact that Android uses cooked ROM's and has to be flashed like WinMo is what i have deduced to be the problem.
Because it's an entire new image vs OS composed of pieces like BB, the system settings aren't aware of where anything is located and cannot restore said system settings.
Am i correct? That's my guess.
Also, someone tell me what the -o is in "mount -o" ......driving me nuts. :icon_eek:
Trust me. A Droid is a LOT more a computer than it is a phone. Is should have a backup/restore feature. And it should be included.
-o Options are specified with a -o flag followed by a comma separated string of options. Some of these options are only useful when they appear in the /etc/fstab file. The following options apply to any file system that is being mounted (but not every file system actually honors them - e.g., the sync option today has effect only for ext2, ext3, fat, vfat and ufs): async All I/O to the file system should be done asynchronously. atime Update inode access time for each access. This is the default. auto Can be mounted with the -a option. defaults Use default options: rw, suid, dev, exec, auto, nouser, and async. dev Interpret character or block special devices on the file system. exec Permit execution of binaries. group Allow an ordinary (i.e., non-root) user to mount the file system if one of his groups matches the group of the device. This option implies the options nosuid and nodev (unless overridden by subsequent options, as in the option line group,dev,suid). mand Allow mandatory locks on this filesystem. See fcntl(2). _netdev The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system). noatime Do not update inode access times on this file system (e.g, for faster access on the news spool to speed up news servers). nodiratime Do not update directory inode access times on this filesystem. noauto Can only be mounted explicitly (i.e., the -a option will not cause the file system to be mounted). nodev Do not interpret character or block special devices on the file system. noexec Do not allow direct execution of any binaries on the mounted file system. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.) nomand Do not allow mandatory locks on this filesystem. nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.) nouser Forbid an ordinary (i.e., non-root) user to mount the file system. This is the default. owner Allow an ordinary (i.e., non-root) user to mount the file system if he is the owner of the device. This option implies the options nosuid and nodev (unless overridden by subsequent options, as in the option line owner,dev,suid). remount Attempt to remount an already-mounted file system. This is commonly used to change the mount flags for a file system, especially to make a readonly file system writeable. It does not change device or mount point. ro Mount the file system read-only. rw Mount the file system read-write. suid Allow set-user-identifier or set-group-identifier bits to take effect. sync All I/O to the file system should be done synchronously. In case of media with limited number of write cycles (e.g. some flash drives) "sync" may cause life-cycle shortening. dirsync All directory updates within the file system should be done synchronously. This affects the following system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename. user Allow an ordinary user to mount the file system. The name of the mounting user is written to mtab so that he can unmount the file system again. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid). users Allow every user to mount and unmount the file system. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line users,exec,dev,suid). context=context, fscontext=context and defcontext=context The context= option is useful when mounting filesystems that do not support extended attributes, such as a floppy or hard disk formatted with VFAT, or systems that are not normally running under SELinux, such as an ext3 formatted disk from a non-SELinux workstation. You can also use context= on filesystems you do not trust, such as a floppy. It also helps in compatibility with xattr-supporting filesystems on earlier 2.4.<x> kernel versions. Even where xattrs are supported, you can save time not having to label every file by assigning the entire disk one security context.
A commonly used option for removable media is context=system_u
bject_r:removable_t.
Two other options are fscontext= and defcontext=, both of which are mutually exclusive of the context option. This means you can use fscontext and defcontext with each other, but neither can be used with context. The fscontext= option works for all filesystems, regardless of their xattr support. The fscontext option sets the overarching filesystem label to a specific security context. This filesystem label is separate from the individual labels on the files. It represents the entire filesystem for certain kinds of permission checks, such as during mount or file creation. Individual file labels are still obtained from the xattrs on the files themselves. The context option actually sets the aggregate context that fscontext provides, in addition to supplying the same label for individual files.
-o Options are specified with a -o flag followed by a comma separated string of options. Some of these options are only useful when they appear in the /etc/fstab file. The following options apply to any file system that is being mounted (but not every file system actually honors them - e.g., the sync option today has effect only for ext2, ext3, fat, vfat and ufs): async All I/O to the file system should be done asynchronously. atime Update inode access time for each access. This is the default. auto Can be mounted with the -a option. defaults Use default options: rw, suid, dev, exec, auto, nouser, and async. dev Interpret character or block special devices on the file system. exec Permit execution of binaries. group Allow an ordinary (i.e., non-root) user to mount the file system if one of his groups matches the group of the device. This option implies the options nosuid and nodev (unless overridden by subsequent options, as in the option line group,dev,suid). mand Allow mandatory locks on this filesystem. See fcntl(2). _netdev The filesystem resides on a device that requires network access (used to prevent the system from attempting to mount these filesystems until the network has been enabled on the system). noatime Do not update inode access times on this file system (e.g, for faster access on the news spool to speed up news servers). nodiratime Do not update directory inode access times on this filesystem. noauto Can only be mounted explicitly (i.e., the -a option will not cause the file system to be mounted). nodev Do not interpret character or block special devices on the file system. noexec Do not allow direct execution of any binaries on the mounted file system. (Until recently it was possible to run binaries anyway using a command like /lib/ld*.so /mnt/binary. This trick fails since Linux 2.4.25 / 2.6.0.) nomand Do not allow mandatory locks on this filesystem. nosuid Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.) nouser Forbid an ordinary (i.e., non-root) user to mount the file system. This is the default. owner Allow an ordinary (i.e., non-root) user to mount the file system if he is the owner of the device. This option implies the options nosuid and nodev (unless overridden by subsequent options, as in the option line owner,dev,suid). remount Attempt to remount an already-mounted file system. This is commonly used to change the mount flags for a file system, especially to make a readonly file system writeable. It does not change device or mount point. ro Mount the file system read-only. rw Mount the file system read-write. suid Allow set-user-identifier or set-group-identifier bits to take effect. sync All I/O to the file system should be done synchronously. In case of media with limited number of write cycles (e.g. some flash drives) "sync" may cause life-cycle shortening. dirsync All directory updates within the file system should be done synchronously. This affects the following system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename. user Allow an ordinary user to mount the file system. The name of the mounting user is written to mtab so that he can unmount the file system again. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line user,exec,dev,suid). users Allow every user to mount and unmount the file system. This option implies the options noexec, nosuid, and nodev (unless overridden by subsequent options, as in the option line users,exec,dev,suid). context=context, fscontext=context and defcontext=context The context= option is useful when mounting filesystems that do not support extended attributes, such as a floppy or hard disk formatted with VFAT, or systems that are not normally running under SELinux, such as an ext3 formatted disk from a non-SELinux workstation. You can also use context= on filesystems you do not trust, such as a floppy. It also helps in compatibility with xattr-supporting filesystems on earlier 2.4.<x> kernel versions. Even where xattrs are supported, you can save time not having to label every file by assigning the entire disk one security context.
A commonly used option for removable media is context=system_u
bject_r:removable_t. Two other options are fscontext= and defcontext=, both of which are mutually exclusive of the context option. This means you can use fscontext and defcontext with each other, but neither can be used with context. The fscontext= option works for all filesystems, regardless of their xattr support. The fscontext option sets the overarching filesystem label to a specific security context. This filesystem label is separate from the individual labels on the files. It represents the entire filesystem for certain kinds of permission checks, such as during mount or file creation. Individual file labels are still obtained from the xattrs on the files themselves. The context option actually sets the aggregate context that fscontext provides, in addition to supplying the same label for individual files.
Also, thanks for the smart@ss answer
What wiki/article did you pull that from. I would like it as a reference.
-o So basically it's a command used to invoke other options within the mounted device. Word.
Sorry for the answer, but you asked.
Since I didn't have a unix system handy, I simply did a google search for "man mount". man pages are unix's manuals.
If people with Droid's want to really learn to be power users on their phones, I suggest learning some UNIX/LINIX.
There is a demo version in the market of MyBackup. I use it when switching between ROMs to backup the stuff that doesn't get backed up - call log, SMS messages, etc. It doesn't get everything, like VPN settings, or your desktop icons, but most.
I would recommend NOT using it to back applications, just go into Market / Downloads on the new phone after setting up your google account. If you use a file based backup/restore, you will no longer receive updates for those apps in the market.
When you get the replacement droid, make sure to switch out the microSD card behind the battery.
I would recommend NOT using it to back applications, just go into Market / Downloads on the new phone after setting up your google account. If you use a file based backup/restore, you will no longer receive updates for those apps in the market.
When you get the replacement droid, make sure to switch out the microSD card behind the battery.
Yes.
Any photos, music, videos, etc you may have transferred, as well as settings for some programs, and backup data, if you use the backup program I mentioned, will be contained on the SD card.
I would also do a Factory Data Reset in Privacy before sending your old phone off.