Hello.
I was performing a backup on a external disk with ntfs Backintime in which uses rsync. I turned off the external drive while I was doing a copy and some files that were copied to the disk can not remove them.
Also I tried rm-rf but I get the following error:
rm: can not remove ‘new_snapshot/backup/home/jonatan/.config/teamviewer8/dosdevices/c:’ Error in/out
As I can delete those files?
Thank you.
My suggestion: Plug the external drive into a Windows system. Then run
CHKDSK /F
on the disk. You might need to do that from an Administrative command prompt.
It is best to let Windows fix broken NTFS file systems.
On 2014-05-21 01:06, jony127 wrote:
>
> Hello.
>
> I was performing a backup on a external disk with ntfs Backintime in
> which uses rsync. I turned off the external drive
That corrupted the ntfs filesystem, and Linux can not repair it. Till
you do, it is mounted read only, and you can not delete things, nor
write to it - just an educated guess.
You need to “repair” that disk using Windows.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
And that leads to the uderlying problem. Why do you use a non-Linux file system for backup? It will not store ownership, etc. and it will give you problems like the above. Better use non-Linux file systems only for exchanging files with non-Linux systems. And making backups does not fall into that category IMHO.
On 2014-05-21 09:46, hcvv wrote:
>
> And that leads to the uderlying problem. Why do you use a non-Linux file
> system for backup? It will not store ownership, etc. and it will give
> you problems like the above. Better use non-Linux file systems only for
> exchanging files with non-Linux systems. And making backups does not
> fall into that category IMHO.
Yes, absolutely.
On an ntfs filesystem you can not store Linux ownership information, nor
file permissions, and I think nor acls. Symlinks are possible, but I
have doubts about hardlinks - and Backintime uses them.
The only way to make backups from Linux to an ntfs/fat filesystem is
using an archive (zip, tar, cpio…).
The exception is, of course, making copies of data files, where
permissions are more or less irrelevant because they all belong to a
single user.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
use ntfs external drives because it is where I store the games iso windows and also use the external drive for backups.
Now leave me worried that Backintime not successful backups in ntfs. The theme of the permits does not worry me too much.
Someone can confirm me if not done correctly Backintime copies ntfs, I do not care about saving the permits.
On 2014-05-21 13:06, jony127 wrote:
>
> use ntfs external drives because it is where I store the games iso
> windows and also use the external drive for backups.
Get another one for Linux 
> Now leave me worried that Backintime not successful backups in ntfs. The
> theme of the permits does not worry me too much.
Depending on what you backup exactly, it may matter a lot.
For instance, if you try to backup and restore the system, it will not
work, simple as that. You can only backup data files, like your
documents on home.
(permissions is vague: some linux permissions specify the file
type, like executable, device, pipe…)
Another problem you may hit is that Linux and Windows (ntfs) do not
allow the same names on files. For instance, in Linux you can have
“mine:financial” as a valid file name. Windows will refuse the ‘:’ and
not backup that file, or “sanitize” it.
Another problem is the charset used for names, so names not purely in
English might not translate. Linux uses UTF-8. Windows, depends.
> Someone can confirm me if not done correctly Backintime copies ntfs,
I do not understand this sentence.
In any case, you need to repair that ntfs disk in Windows.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
I have already repaired properly.
Now I’ve seen that gives windows errors with the character “:”
Only use Backintime to make copies of my home in the ntfs drive. What if I make only copy of my home in ntfs no problem?
That needs a bit of clarification.
If you are backing up to some sort of archive (with “tar” or “dar” or “clonezilla”), then unix permissions/ownership, etc will be in the archive. So NTFS can be okay in that case. But backup by direct copying of files to the NTFS file system will lose important information.
I can only repeat what I said earlier:
Better use non-Linux file systems only for exchanging files with non-Linux systems.
I am only using non-Linux file systems on e.g. an USB stick when somebody comes with something on it from his/her system, or when I have to offer somebody, that has yet not seen the light of Linux, a file. Never for anything else. And I can not give any advice on what under what special circumstances or with what restrictions or with what special handling you may be able to do with non-Linux file systems when you persist on using them.
And backups are to precious to me to put them on such file systems. But you may be happy with it.
On 2014-05-21 15:36, nrickert wrote:
> But backup by direct
> copying of files to the NTFS file system will lose important
> information.
As he is using an rsync variant, that is the case.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Would use a linux file system, the problem is that the two external drives are ntfs because I store them .iso games that use windows, so they are ntfs and take the opportunity to back up on them.
I do not have an external hard drive exclusively for backing up my home, it would be a waste a disc for that only and additional expense.
jony127 wrote:
>
> Would use a linux file system, the problem is that the two external
> drives are ntfs because I store them .iso games that use windows, so
> they are ntfs and take the opportunity to back up on them.
>
> I do not have an external hard drive exclusively for backing up my
> home, it would be a waste a disc for that only and additional
expense.
>
Can you reconfigure your external drive or do you have extra space?
What I’ve done with my 1TB External WD My-Book drive is:
sdc1 Fat approx 100Gb (used by Windows0
sdc2 Ext4 400GB (openSUSE 12.3 Backup)
sdc3 Ext4 500GB (openSUSE 13.1 Backup)
Has worked fine for several years and has never failed to restore a
folder or file. i backup /home, /etc and other miscellanous stuff.
openSUSE 13.1(Linux 3.11.10-7-desktop x86_64|
Intel(R) Quad Core™ i5-4440 CPU @ 3.10GHz|8GB DDR3|
GeForce 8400GS (NVIDIA-Linux-x86_64-331.67)|KDE 4.13.1
Although I don’t use backintime,
I skimmed the documentation… so my observations may be unreliable but
Permissions (ACLs) can be preserved. Default is no, but can be enabled (@nrickert, I doubt that any fs should not support preserving FS permissions when moving or copying to a same fs, it may just not be default. After all, permissions are simply metadata associated with the file)
http://backintime.le-web.org/documentation/settings-dialog/
Maybe someone might have a different experience, but the few times I’ve personally used rsync, it maintains an exact target copy of the source. I don’t know if rsync can support any type of compression of the target because it uses hashes to determine file integrity and changes. Compression is possible when transporting <between> source and target. So, maybe someone else can opine about rsync between dissimilar file systems (eg from ntfs to a Linux fs) while preserving ACLs (may not be possible)
Just IMHO,
But I feel current Linux FUSE support for NTFS is pretty good., that should not make much difference although in theory it involves slightly more complexity than accessing a natively supported fs.
jony127 I have already repaired properly.
Now I’ve seen that gives windows errors with the character “:”
Only use Backintime to make copies of my home in the ntfs drive. What if I make only copy of my home in ntfs no problem?
@jony127,
If that character causing errors is regular and many, I’d pause a moment to try to determine how that happened, it probably wasn’t by accident and needs to be addressed. Eg. What filenames or whatever is creating or using that character, is it normal and expected? Also, where are you seeing these errors, as part of the chkdisk output? If so, then I typically consider those errors as non-critical and possibly related to lost data. In general, it’s good practice to not rely too much on a repaired fs. If you continue to use it, you probably should continue to run chkdisk regularly and frequently (eg monthly or slightly more often). If this was a critical database, the common recommendation would be to create a backup of your repaired file(s), wipe clean, create a new blank database and restore from backup.
IMHO,
TSU
On 2014-05-21 19:46, tsu2 wrote:
>
> Although I don’t use backintime,
> I skimmed the documentation… so my observations may be unreliable but
>
> - Permissions (ACLs) can be preserved. Default is no, but can be enabled
> (@nrickert, I doubt that any fs should not support preserving FS
> permissions when moving or copying to a same fs, it may just not be
> default. After all, permissions are simply metadata associated with the
> file)
Yes, permissions and such are metadata, stored separately from the
files. The problem is that each filesystem type stores different
metadata, and what a Linux filesystem needs to store as metadata can
simply not be stored as metadata in a Windows filesystem, nor the other
way round.
There is an old tool in “mtools” that can create a metadata archive of a
fat filesystem so that you can create reliable backups of FAT disks in
Linux.
The standard way to create a good backup of Linux in another filesystem
is to use archives.
Another method, instead of repartitioning the disk, is create a loop
filesystem inside the ntfs disk, in any suitable format, and then run
rsync on to it. It can even be encrypted, and compressed if a r/w
filesystem that supports compression can be found (btrfs says it
supports it, but it is an experimental feature, IIRC).
> I don’t know if rsync can support any type of compression of the
> target because it uses hashes to determine file integrity and changes.
Unfortunately, no.
The hashes could be calculated after uncompromising the file, so that
point is moot, IMHO.
> So, maybe someone else can opine about rsync between dissimilar file
> systems (eg from ntfs to a Linux fs) while preserving ACLs (may not be
> possible)
Not possible.
Not ACLS (well, samba does some conversions), nor permissions, nor
attributes. Even file names can give problems: I gave the “:” as an example.
>
> - Just IMHO,
> But I feel current Linux FUSE support for NTFS is pretty good., that
> should not make much difference although in theory it involves slightly
> more complexity than accessing a natively supported fs.
Not much complexity. It adds cpu load, though, so much that in some
machines it is much slower.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))