Am Freitag, 10. August 2018, 04:46:17 CEST schrieb Dale: > Wols Lists wrote: > > On 08/08/18 04:43, Dale wrote: > >> Howdy, > >> > >> I just bought two external drive enclosures. One is sort of a spare but > >> I do plan to do some backups on it, mostly pictures from my camera. In > >> one of the enclosures I put a single 6TB drive that I found on ebay. It > >> has about 7,000 hours on it so it should have some life left yet and it > >> passed the smartctl tests. It is USB but it transfers fast. Now to > >> some questions. I use rsync. Command looks something like rsync -auv > >> /source/ /destination/. If I backup the config files in my home > >> directory, should I also include the --delete option? If after a > >> upgrade for example a config file is deleted, because it is no longer > >> needed, or renamed, should the old file be removed or is there a reason > >> to keep them on the backups? Adding the --delete option isn't a problem > >> command wise BUT I wonder if it can cause a problem at some point. > >> Thoughts on that. I plan to use the --delete option for videos since if > >> I deleted one, it is likely broken or something. Biggest question is > >> about config files. > > > > May I suggest using btrfs for your backup drive? One MAJOR caveat - DO > > NOT let the drive fill up - a combination of snapshots and drive-full > > has been known (quite often) to trash the file system. But provided you > > make sure it doesn't go above about 80% you should be fine. > > > > You can add an option to rsync such that it will back up "in place". In > > other words, if only 1K is changed in a 1M file, it will overwrite that > > 1K. So when you back up, the procedure is to take a snapshot, then run > > rsync with both "in place" and "delete". > > > > This will give you the space economy of incremental backups, combined > > with the utility of full backups - each snapshot is a full backup as of > > that date, but each new snapshot only increases disk usage by the > > changes since the last. And you reclaim space by deleting old snapshots. > > I did think about btrfs. I've read a lot of threads on here about > people using it and it seems to have come a long ways and be pretty > stable. Right now, I've got a lot going on and really don't have the > time to sit down and read up on it and how it works or what all it can > do. In all honesty, if my system were to crash later when I don't have > so much going on, I'd like to move to btrfs for as much as possible of > my system.
Yeah, it's a good idea to wait until you have time :) . And then migrate piecemeal, not all at once. Following up on Wol's suggestion, I would start with the backup drive, since you can exploit most of the features there (well, snapshots and compression, at least). Personally, I've had mostly good experience with btrfs and enjoy its send/receive feature for full-system incremental backups. > I suspect /boot would still have to be ext2 or something > because of grub. GRUB actually supports btrfs. However, on a UEFI system you will need a FAT32 file system for /boot, so I would argue that on a relatively recent system the issue is moot. -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
