From Gentoo Wiki
Jump to: navigation, search
This is a talk page. Please add newer comments below older ones, and sign your comments using four tildes (~~~~). When adding a new section (at the bottom of the page), please mark it as "open for discussion" by using {{talk|open}} so it will show up in the list of open discussions.

Move to base config file

Talk status
This discussion is done.

I think that for correctly rotate rsnapshot need to know all the "intervals" now "retain" params. As stated in

Each subsequent time rsnapshot is run with the hourly command, it will rotate the hourly.X directories, and then “copy” the contents of the hourly.0 directory (using hard links) into hourly.1.
When rsnapshot daily is run, it will rotate all the daily.X directories, then copy the contents of hourly.5 into daily.0.

So probably we need to move them all in the base configuration file. --Bfx81 19:03, 2 July 2012 (UTC)

I was going to suggest the same thing, the man page says the same:

Backup levels must be specified in the config file in order, from most frequent to least frequent. The first entry is the one which will be synced with the backup points. The subsequent backup levels (e.g., daily, weekly, etc) simply rotate, with each higher backup level pulling from the one below it for its .0 directory.


retain hourly 6

retain daily 7

retain weekly 4

daily.0/ will be copied from hourly.5/, and weekly.0/ will be copied from daily.6/ hourly.0/ will be rsynced directly from the filesystem. So all the hierarchical levels of backup show be moved to the base file, and rsnapshot will know which one to run from the argument given to it (monthly/weekly/whatever you name them in the config). --Luscinius (talk) 05:03, 8 November 2013 (UTC)

done + some more intution and pit falls explained --Tillschaefer (talk) 19:32, 16 September 2014 (UTC)

I was the original author of this article. My intent was to save different things at different intervals, which is why I had separate config files for each interval. Indeed, if you want to rotate from shorter intervals to longer intervals, and not just within each interval, you need to specify the different intervals in one config file. The downside here is that it makes the backup process longer for the shortest interval, since you will likely want to process the whole filetree, not just a portion. --Hypnos (talk) 16:06, 14 March 2015 (UTC)

I do not think that the last sentence is true. AFAIK rsnapshot simply renames the last shortest interval snapshot to the first proceeding interval snapshot, etc. Therefore, rsync is only called on comparison with the last shortest interval snapshot. In the "different files version" you will traverse the file system for each interval separately, which causes a higher load and a higher disc utilization. You will also end up with some snapshot being nearly identical in daily, weekly, etc snapshots. --Tillschaefer (talk) 17:55, 14 March 2015 (UTC)

It depends on which interval covers the most files. In my setup, I have my home directory daily, /etc/ and /var/db/pkg/ weekly, then the rest of the filesystem monthly. If my home directory is small, then most disk usage is monthly. In the combined setup, the entire disk is done daily, then copied over weekly and monthly. This all said, I think the combined setup is most appropriate for the Wiki since it's simpler, and with SSDs for both source and destination it's not a big difference anyway. One question: are the filepaths in the restoration section correct? They're correct for the original setup I authored, but I'm not sure for the combined setup. --Hypnos (talk) 01:20, 15 March 2015 (UTC)

Well. i previously deleted the above paragraph (17:55, 14 March 2015 (UTC)) of me, because i did noticed myself, that I misunderstood the setting in the first place. So I am with you that you setup is more efficient for differernt folders if the shortest invertall differs a lot. Regarding the restoration: You are right. In the current setup the localhost folder path is added and no hidden files at the root directly are considered. I wil fix this. --Tillschaefer (talk) 11:14, 16 March 2015 (UTC)

Suggestion: Remove or soften the "crazy enough" opinion about Btrfs

Talk status
This discussion is done.

Sure enough, it's still easy to find some dangerous or plainly broken features hidden at plain sight (like RAID-5/6 profiles, or the space-cache-v2-tree, etc) but I think a single disk or mirrored Btrfs filesystem, when used reasonably (keeping the utilization of the fancy functions at a minimum rather than abusing them in an unreasonable, stress-test like fashion [like, in this topic, creating and keeping countless snapshots and then deleting them all at once]) is considered stable enough, especially if it's contents are regularly backed up. It's far from dangerous enough to require a mental illness, I guess. — The preceding unsigned comment was added by Janos666 (talkcontribs) October 2016‎

Hi. This is a publicly modifiable wiki. You can feel free to remove, edit, change, adapt, improve, etc. information that has inappropriate bias. With that being said I have fixed the article for you. Please also remember to sign your comments on discussion pages. Kind regards, --Maffblaster (talk) 23:24, 20 December 2016 (UTC)