Tuesday, February 26, 2019

external drive ext4 and ntfs side by side - permissions

https://www.linuxquestions.org/questions/linux-newbie-8/i-set-up-an-ext4-partition-on-external-hd-to-store-media-files-permission-issues-4175469722/

backup data from ext4 drive

Source: https://askubuntu.com/questions/963442/backup-ext4-data-to-exfat-partition

"
I advise you against using rsync. You should use either rdiff-backup, Duplicity, or Borg Backup.
rsync is great for mirroring – that is: syncing – folders. You, however, probably want a backup. Imagine you accidentally delete something, then your cron job starts a sync before you can stop it. This means you just lost that data, even though you thought you had a backup. But you only had a mirror. Now if you already made a copy of that copy, you can get your data back as long as that's not already overwritten, too. But if you don't notice your mistake for some time, your data is lost.
Now, there is an rsync switch (-b/--backup) to prevent this. But you're probably still better off using a tool which is actually designed for making backups.
rdiff-backup is such a tool. It does, however, lack encryption.
Duplicity offers encryption. I did, however, make the personal experience that it doesn't restore data reliably. That is, when I tried to get a folder back to a previous state, the one file I really cared about just wasn't restored. And I know that file existed before for months because I just accidentally screwed it up, right before I wanted to restore it. Duplicity wouldn't let me restore that file and when I tried to get the folder back to various points in time, all of which I would've been fine with because there were no major changes to that file for months, it just didn't put that file in the restored folder and didn't even print a hint indicating that that file was missing.
I don't know whether this is actually a problem with Duplicity or whether it's a problem with Deja Dup as I used Deja Dup (which uses Duplicity, which in turn uses rsync, btw.) for backing up. I did, however, try restoring the file/folder both via Deja Dup and directly via Duplicity. It didn't work.
About half a year ago, a friend of mine asked me about how I do my backups. The reason she asked me was because she experienced the exact same problem with Deja Dup.
As my trust in Deja Dup was already gone after I experienced the problem myself, I switched to Borg Backup, which I recommend you should too.
Borg Backup takes a bit to get started on but once you know how it works, it's great. It offers versioning, encryption, compression, and deduplication. Backups with Borg Backup are faster than with Deja Dup and you get to enjoy awesome features like being able to mount your backup repository.
That is, you issue a mount command and then enter the location you mounted your repository to. You will then see a list of backup labels as folders. You can enter any one of these folders and look for your files. No need to restore them revision by revision. They're just all there in the mounted repo.
This means you can use normal command-line features and tools on those revisions. For example, I recently found out that I accidentally deleted my Firefox desktop file some time ago. Didn't notice for weeks. A simple
ll */home/christoph/.local/share/applications/firefox.desktop
in the mounted directory gave me a list of all the revisions containing that file. I simply copied the newest one out. But if you wanted, you could take that list and do a diff on the results to see what changed without having to restore anything first. Plus, mounting and searching the repo was way faster than the time Deja Dup takes to just figure out what file is gone.
If you use Borg Backup, it will actually keep track of ownership and permissions without the file system in the backup location having to support ownership or permissions as those are encapsulated by Borg.
Borg can be used perfectly well with cron jobs. It's just a single command you need to issue. There is an archive name you need to specify which needs to be a different one for each backup. If you issue the commands by hand, you can write something more meaningful in there. I simply use date +%c for archive names because my backups are created automatically.
Storing your first backup on a FS with journaling is certainly a good idea. As you then only create other backups and it's not terrible if you have to throw the FS your 2nd backup is on away because it got compromised when the power went out, using a non-journaling FS for it is acceptable.
You can sync this second backup from the first one via rsync. There is no problem with this as you already made sure you can go back to previous versions via Borg Backup, and – if you want – Borg already took care of encryption, too.

"