LB copied every data file to NFS share
...a powerful, fast and reliable backup & sync tool.
Brought to you by:
luckyb69
Menu
▾
▴
Loukas, I had a systen disk go bad and had to install a new one. I booted a Live DVD of Ubuntu 18.04.5 and idid a clean install. Since I had a backup of my home directory, I restored that over the new home directory. With a nminimum of work, I got all profiles working and installed all my missing aspps. Everything was mounted at the same mount points. I opened LuckyBackup, and my jobs were there. The first job in the list is to backup my Data disk to an NFS share. What puzzeled me was LB replaced every file that was on the disk as well as any new files. This only happened the first time I ran this job, Any thoughts on why this occured? I dismounted the share to make sure LB wasn't writting to the mount point with the share not mounted. There was nothing there after the unmount.. I mounted the share, and my files were all there. So LB was definitely copying everything to the share, even file that had been there for soom time. Was this expected behavior? Thanks.
hey ;)
Normally, for LB to trigger a transfer, either the size or the last modification time of files between source and destination have to differ.
If you can confirm that (just for a couple, not all files), then it is normal behaviour.
Hopefuly it will copy all data over the first time (although it looks like it was already there) and then it will just backup the changed files
Well. I know many of the files were the same size and date, but the next run will tell us something. If it runs normally, I won't worry about it, but if it copies everything again, I must have a wrong setting.. I'll let you know. I will do a backup tonight.
Well everything seemed to run as usual, but I got the following message:
rsync: readlink_stat("/nfs/Ubuntu_Data_Backup/.moneydance/Documents/Carpenter Financials.moneydance/safe/tiksync/out/.20171123183548_928.txn.AjKJ0O") failed: Input/output error (5)
What is happening here?
Loukas, I am still having this problem:
IO error encountered -- skipping file deletion
rsync: readlink_stat("/nfs/Ubuntu_Data_Backup/.moneydance/Documents/Carpenter Financials.moneydance/safe/tiksync/out/.20171123183548_928.txn.AjKJ0O") failed: Input/output error (5)
Why is this occurring?
Hello,
An IO error can come up due to permission issues (hopefully) or even when there is a disk failure.
When rsync encounters such an error, it will skip the --delete-after argument for safety reasons.
Is that happening only for one file ?
If you navigate at the destination at:
nfs/Ubuntu_Data_Backup/.moneydance/Documents/Carpenter Financials.moneydance/safe/tiksync/out/
Do you have read & write permissions there ?
I have full permissions on the folder as well as all files in the folder.
Here's something odd. I searched both the source and the target for the file .20171123183548_928.txn.AjKJ0O. There is no such file on either disk. There are files on both the source and target named 20171123183548_928.txn. No files begin with . (dot). And yes, I have Nautilus set to show hidden files. So why is LuckyBackup even referring to the file in the error message?
Last edit: cscj01 2020-09-14
LB (well, ...rsync) will create temporary files (in the form of [dot][original filename].[random string]) while transfering data from source to destination and when everything is fine in the end it will rename the temp file to its normal filename.
More info on this can be found here at the receiver paragraph.
Could you please confirm the permissions and ownership of the 20171123183548_928.txn file .
Can you simply copy this file at another location ?
Yes, I can copy both files - the one in /nfs/Ubuntu_Data_Backup/.moneydance/Documents/Carpenter Financials.moneydance/safe//tiksync/out and the one in /media/Data/.moneydance/Documents/Carpenter Financials.moneydance/safe//tiksync/out. Those are the target and source files respectively. Once again, there is no file named .20171123183548_928.txn.AjKJ0O which is the one showing up in the error message.
As you mentioned in your post, it's as if the file was copied but the temporary file was not deleted for some reason, although the temporary does not exist in my system (at least on my source and target disks.)
Could you also try the following commands so that we find out about the file's permission:
My thought is that this might be caused due to write permissions at the destination file
ls -l /nfs/Ubuntu_Data_Backup/.moneydance/Documents/'Carpenter Financials'.moneydance/safe//tiksync/out/20171123183548_928.txn
-rwxrwxrwx 1 butch butch 4832 Dec 13 2018 '/nfs/Ubuntu_Data_Backup/.moneydance/Documents/Carpenter Financials.moneydance/safe//tiksync/out/20171123183548_928.txn'
ls -l /media/Data/.moneydance/Documents/'Carpenter Financials'.moneydance/safe//tiksync/out/20171123183548_928.txn
-rw-r--r-- 1 butch butch 4832 Dec 13 2018 '/media/Data/.moneydance/Documents/Carpenter Financials.moneydance/safe//tiksync/out/20171123183548_928.txn'
So the permissions are different. Do you want me to change the permissions? If so, which one, source or target?
Try to delete the one at the destination and run the task to check if it will be created with no issues
I deleted the file on the target disk. When I ran the job last night, I received the same error message.
damn !!
I really hope this is not the case, but could you check your drives for errors (eg with fsck) ?
Well, I did fsck on the source and disk is fine. I tried from client side to do fsck on target, but the system would not let me do it. I then realized the target was an NTFS disk. I decided to reformat it to ect4. After that, all files were transferred with an error because LB could not access lost+found. I fixed those permissions and am happy to report that all is well with LB.. Loukas, thanks for hanging in there with me on this. The target was NTFS from back when I had a dual boot 10 or 12 years ago, and I had never changed it. In a way, I am glad this happened. I ran fsck on the target with no problems. Thanks again.
Last edit: cscj01 2020-09-24