ood morning hello dear community,
well - i am working on the setup of a notebook - (erasing the old ubuntu ) and installing a new OS.
therefore i need to copy all the data.
how to proceed: how to copy (all!) the data from one notebook to a external drive
how to copy the data from one notebook to a external drive -
note: i want to move the whole data - i want to do a complete frehs install - therefore i need to save all /(!) the data:
how to achive that - how to get really each byte!?
a. with the bookmarks of the browser
b. the hidden data.
c.
are there some certain commands that ensure that i really get all the stuff!?
look forward to hear from you
Update some additional thoughts:
how do you find this idea: what if i just create a new folder in my /home called ‘
Alltogther’ .
what if i do it like so: i firt copy / paste all the pre-existing folders into “Alltogehter”.
hmm - it would be great if i know a good command for the terminal
and subsequently:
well that said . i could then finally copy the so called " Alltogether-folder" into my backup location.
what do you say - i think that this solution is very interesting.
question: how would you do the job of coping all the data!?
look forward to hear from you
greetings
The issue, as presented in post #1 is to copy "all the data" and "each byte".
The answer to copying all the data, meaning each byte, is to clone.
@f33dm3bits however in post #6, asks the question whether you want to backup files in order to restore them later, to which there doesn't seem to have been a succinct answer yet.
There's a significant difference between cloning and backing up files. The foxclone website explains it in the following text from this document on its website:
https://foxclone.org/downloads/foxcloneV50.pdf
Code:
Foxclone V50
Page 5 of 64
How should it be used?
2. It cannot be stressed strongly enough – a partition backup utility such as
foxclone or clonezilla or any other image backup tool should not be used as
your only backup tool.
3. A partition backup utility is there for disaster recovery:
* A failed or failing drive.
* An operating system borked (usually by the user) to the extent that it will
no longer boot.
4. It should not be used as a daily backup tool, why?
* It is a manual process, you cannot automate it, at some point you will
forget to do it.
* It is slow, you have to backup up complete partitions. There is no
incremental or differential backup to speed things up.
* It doesn’t understand files and folders, just partitions. Mess up a few
files, you have to restore the entire partition probably overwriting
newer files that were perfectly okay, potentially leaving you worse off.
Problem dependent, it can be a sledgehammer to crack a nut.
5. An image backup tool, such as foxclone, should be used in conjunction with a
file level backup tool(s). There are plenty of excellent Linux file backup
utilities, timeshift, backintime, luckybackup to name just three. These:
* Are installed in your running system. You do not have to boot a
separate operating system, e.g. from a USB stick. More convenient.
* Can be automated to run daily or at whatever frequency you want.
* Are incremental – they only backup files that are new or changed – so
quick.
* Allow you to restore individual files – just the ones you broke!
Use file level backup as your first line of defence.
Use image backup as your last line of defence.
Basically the essence is captured in the metaphor that sees cloning as a "sledgehammer to crack a nut".
Cloning can be an effective solution for disaster recovery, and also for copying a whole installation bit-by-bit to another suitable drive and then trying to have that second drive boot up the same or similarly to the original installation of which it is a copy.
In relation to backing up files, which is the central concern with backing up so that files are not lost and can be easily recovered, the economy and efficiency in the use of resources is greatly more optimal with use of appropriate back up tools, procedures and processes which do not involve cloning at all.
In considering the two examples for backing up mentioned in post #1, "the bookmarks of the browser" and the "hidden data", the following thoughts occur.
To take the firefox browser as an example, one can make a copy of the bookmarks by using the menu items:
Bookmarks -> Manage Bookmarks -> Import and Backup -> Export Bookmarks to HTML
which will write a file with all the bookmarks used in the browser named "bookmarks.html". It's a file of about 450K on this machine which has about a 200 bookmarks. A clone, on the other hand, will copy the whole .mozilla directory entry that runs firefox's profiles, which on this machine amounts to over half a gigabyte:
Code:
[~]$ cd .mozilla
[~/.mozilla]$ du -sh
587M
That sort of finding exhibits the notion of a "sledgehanmmer cracking a nut" almost perfectly. Most browsers I'm familiar with include a facility to copy the bookmarks to a file.
Further, since a new installation of firefox would populate its profile with all the relevant files that make up the total disk usage in a new distro installation, it's hard to see the point in storing the old installed files in a backup in any form. With a new installation, one can import the relatively small bookmarks.html file, and have lost nothing of importance. About other configurations which one might wish to keep from a browser, see the comments below.
In the case of using the clone as the backup, one has to restore the whole clone to then be able to access any single file. That is its central archilles heel from a back up point of view.
Looking at the second example of backing up hidden files, which I take to be the dotfiles in the /home/$USER directory, there are different issues, but again, backing up the lot has the same issues as those mentioned with firefox above. To make a couple of points about these files, some are configuration that a user can write, and others are configuration files that the applications themselves create either automatically using default values, or have alterations to those defaults made by the user of the apps. The only elements that need to be backed up are the settings that the user has made to alter the defaults, because when a new installation of those apps is made, the app will set all its default configuration again which relieves the user from having to set defaults that will enable the app to function as intended.
Backing up the alterations a user has made in configurations of an app can be a complex matter with a lot of details. There are different ways to manage it for the purposes of backup. In my case, I keep a text file with notes on the alterations made, and back up that relatively small text file. That file, or sometimes multiple files, also includes the alterations to configurations I've made to the configuration files in the /etc directory.
All in all, I believe effective and efficient backing up involves backing up files that one doesn't wish to lose rather than cloning a system or partition. One is best to use the appropriate tools for the job of backing up rather than adapt ones that don't fit as well despite what they appear to do.There's quite some thought that can go into how one might effectively backup. A common and straightforward way is to use the rsync tool in a script that can backup all the relevant files. There are numerous scripts online to help users, and also a number of backing up apps that themselves use rsync for the job. As with most aspects of linux, there's a learning curve involved. I think it's worth the effort to climb it a little to avoid inefficient ill-fitting "solutions" that may have superficial appeal.
There's a lot more that can be said about backing up, but I'll end the rave here
.
