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