File Backup
What's the best way in Linux to backup files and folders?
Currently my personal files are 48.5 GB large, 38,466 files with 2,971 sub-folders. I try PCManFM and Dolphin FM, but they end up failing half way through around 50% of the time. I have right clicked in PCManFM to compress, but after it compresses everything, when go into the tar.gz with archive manager, not all folders are there! Maybe is entering some command in Terminal the only secure way? |
You can create compressed tar backup using tar command
tar czf <path <tarfilename> <path of folder to be backuped> Thanks |
andrew.comly,
Hi, Welcome to LQ. Quote:
Quote:
There are of course good commercial backup utilities for Gnu/Linux, but the same objective can be attained by simple terminal commands. Use 'rsync', simple and sure. Code:
~$ rsync --archive /personal/files /mounted/volume/ Code:
~$ man rsync Good luck. |
You can create a .tar of multiple files, and then compress the tar file.
To create a .tar: Code:
tar -cvf sample.tar /path/to/file(s) Code:
tar -tvf sample.tar Code:
gzip /path/to/file Code:
tar -ztvf /path/to/file |
were are you putting the backup files? are they going to a NAS, to an other computer, to the same computer in a different directory? were.... this makes a slight difference in how best to backup the data.
if going to a NAS, then you might want to just look into either mounting the CIFS mount point and moving the data around, or you could even activate FTP on the NAS and use lftp to transfer a tarball, see above on how to create, to the NAS. if going to an other Linux computer then rsync with ssh keys would be the best way to go. rsync would also be a great way to move the data around locally too. I typically will use: rsync -aviS /souce/files /destination/ for my backups. with this much data you will see a network hickup so you might want to run this at night via cron, or you might want to consider adding -z in there for compression. see the man rsync for more details. |
Quote:
The above "sudo tar -cvf AC20121229.tar /mnt/D/AC" yields the following: tar: AC20121229.tar: Wrote only 4095 of 10240 bytes tar: Error is not recoverable: exiting now " |
how about you copy/paste the exact output of the command for us as well as answer the above questions about location and space.
you can run df -Th from either $ or # after you have mounted the destination. |
To those recommending gzipped tar files, that is a bad idea. Personally I would copy the files (perhaps with rsync) to an external disk using a linux formatting scheme. If you need to copy to a disk or network drive where UNIX file permissions and attributes cannot not be maintained (e.g. using a disk using a Windows file format) and want to use an archive format to retain permissions/attributes, consider the implications of gzipping the archive itself.
To expand I'll link to a post I made previously on this topic: Quote:
Quote:
|
Two more thoughts to the original poster:
Older versions of gzip had problems decompressing files larger than 4Gb (e.g. gzip 1.2.4 had such an issue). Your member info that that you use Lubuntu 12.10 so in theory this should not be a problem (as it ships with gzip 1.5) but perhaps you are describing an issue on another machine with an older distro (and hence an old gzip)? If yes, that could be your problem. There are multiple tar implementations, which can use different default formats (additionally some distros compile GNU tar with different defaults). Modern GNU tar should have no problem with such a large archive as long as you are using GNU or PAX formats. To be 100% sure one of these is being used I would specify either --format=gnu or --format=pax. That all said, I would once again suggest either doing a straight copy (perhaps with rsync), using a tar without compression or using another archive format that can do internal compression. |
I am extremely busy on weekends, but I will have some spare time starting on Sunday night(China time), any patience is much appreciated!
Andrew Comly |
rsync seems to work, but...
1 Attachment(s)
Your "~$ rsync --archive /personal/files /mounted/volume/" was most helpful. In addition, I did add on a few extra options after reading the "rsync --help" in detail to make the following:
rsync --archive -vE --delete --stats /media/a/AC/Recent/AC/ /AC I found the above "--stats" option quite useful, giving the essential number of files information as the attached jpg indicates. Unfortunately, no "number of folders" info given, and worst of all due to my system crashing after I tried a "tar --format=gnu" command, I am reluctant to install dolphin(it's built for Kubuntu, not Lubuntu). How can terminal be used to look up the # of folders information for the above job, and how may I obtain both the # of files and folders in the source folder? Indeed part of backing up information should definitely include verifying copied information matches source information exactly, this detail is quite essential. |
Outcomes of "tar -... --format=gnu SOURCE TARGET"
The tar command just didn't work, I tried the "--format=gnu" option and it only copied ~20% of my information.
Strangely enough a few minutes after this I encountered a strange crash error message that took me to the official KDE report bug reporting website, but due to not having some 'gpd' (or something like this) program installed, I just wasn't able to report the vital crash information. Even when I then opened terminal up using the "sudo apt-get xxx" didn't work, giving me the erroneous information that my disk space wasn't enough. This is quite absurd due to the fact on my Samsung at that time the drive I used for my personal files was on a different partition that the system files, more specifically: sys drive - 80GB; personal file drive 100GB, with no more that 15GB used on the system drive. More specifically terminal reported that there was insufficient space needed to install the mere 5KB of space the '~gpd' program would require. I wonder if the crash is due to the fact that I was running dolphin FM and PCManFM concurrently, dolphin is originally made for KDE/Kubuntu, not Lubuntu. This might explain the KDE ladybug crash report website. Anyways, I then rebooted to find the dreaded black page with only a blinking cursor. I then rebooted from the Lubuntu 12.10 flash drive trying first the "~reinstall system only" option (the option to re-install Lubuntu without deleting installed programs) which didn't work, so I ended up having to completely reinstall everything. I don't certainly don't blame your advice for this, but I just thought I should offer you information of what happened after I tried the above “tar –format=gnu SOURCE TARGET” command. Certainly the rsync command should do the job, except I don't know how to verify # folders/files on both the target and source files match now without dolphin. I dare not install dolphin again, is there some way to use terminal to obtain this information? |
Quote:
You can monitor everything what rsync is doing --even what errors are happening behind-- into a file which you can examine by grepping or searching on it whatever you query later after the job is done: this means you can put everything on a record file. Try this: Code:
rsync --archive source/ destination/ >myrecord.txt 2>&1 Code:
grep -li filename myrecord.txt or BTW, just a point of reminder: if you deal with huge quantity of files on huge volumes it is most advisable to use the terminal (rsync), not file managers like dolphin where memory resource is handled differently. Hope that helps. Good luck. |
rsync --archive /src /destination >myrecord.txt 2>&1: Error MSG
1 Attachment(s)
malekmustaq,
Thanks for your idea. Unfortunately when trying this I encounter the following message error message (screen snapshot attached): a@SAM:/$ sudo rsync --archive --delete --vEu --stats /AC /a/home/AC >myrecord.txt 2>&1 <Enter> bash: myrecord.txt: Permission denied The above error message is still present when writing "sudo" in front of the above command, even when I make a "myrecord" file (no .txt since a leafpad document) before executing the above command in the "/" directory, the same "bash: myrecord.txt: Permission denied" is still encountered. Andrew Comly |
rsync: Source & Destination still doesn't exactly match.
1 Attachment(s)
malekmustaq / All others :-),
So after I ran the “rsync --archive --delete -vE -u --stats /AC /home/a/AC” command, and it seemed to work. Next, in order to check a match between the source and destination files, I looked up on a Mac OSX hints webpage and discovered the concept of combining the two commands of “ls” and “wc” together, and received the following result: a@SAM:/$ cd /AC a@SAM:/AC$ ls -R | wc -l 46789 a@SAM:/AC$ cd /home/a/AC a@SAM:~/AC$ ls -R | wc -l 46781 I didn't take any Computer Science classes, but isn't the subject of computers supposed to be a “hard” science? If so, why am I still short 8 files? I guess computer science just isn't as much of a "hard science" as mathematics or physics! {hard science = science in which facts and theories can be firmly and exactly measured, tested or proved, as opposed to soft science, e.g. sociology or economics} Sincerely, Andrew |
All times are GMT -5. The time now is 11:10 PM. |