Second language mistake (frame vs chassis) and profanity aside, I still can't confirm the 100% thing. [1] is interesting though. Still not 'almost 100%', but the truth is, as usual, somewhere in the middle.
[1] http://www.worldautosteel.org/...
Do you have a source for your 100% recycling claims? I know people who worked with the car recycling industry, and they said quite the opposite. Recycled steal isn't allowed in the frames. and recycling is dang hard, not to mention an afterthought. They smash the car to bits and use eddy-current separation to get the metals, but that is by no means pure.
I tried disabling it, and immediately got calls from people that 'a trust relationship can't be established with the central logon server' or some such thing when they tried to log in.
Seeing as how I remembered my Win95 (20 chars) and Win98 (25 chars) serial keys just from reinstalling every two months, I think I would remember that password quite quickly, having to type it every day.
I actually still know those serials...
Depends on the situation. If you're restoring from another system, such as a live CD, --numeric-owner is vital, or users can be messed up. All the GIDs en UIDs of the system you're using to restore are not identical to the ones of the system your restore. Therefore, name matching by string is not reliable.
Rdiff-backup uses mtime+size as a unique identifier. The author tried using ctime, but there were problems with that. Unfortunately, he couldn't remember what they were... Ben Escoto (the author) told me so personally.
I don't have any official "credentials"... When I talk about machines, I mean Linux machines. I should clarify the intro about that (the word "mostly" should be removed). Debian, Slackware, Gentoo didn't have it, per default.
But I don't need crediantials to let this article be useful to anybody, I would say. People can agree or disagree with the points I make of their own accord.
Actually, I burn them to DVDs. But, I don't really have one specific target audience in mind. Large enterprise setups require more work and more specific apps, of course. I didn't know of Amanda, but I have it on my TODO.
As I stated in the intro, my experience is with Linux (perhaps I should remove the word "mostly"...). The lack of dump on Linux can be blaimed for my ignorance. But, I will investigate it, of course.
True, but my assumption (which again, I haven't checked) is that they wouldn't have stored this hash if they weren't doing something with it. I don't think the sanity check uses any information that's not gathered for normal operation.
The hash information feature was included after I suggested a feature for hash-change-checking. The hash is already stored, because that was easy to do, but the change checking never got implemented.
True. Your backup from before the move will be correct, so if you were to catch this before you got rid of the pre-move increment, you'd have a way to recover manually. I assume you're talking about after that. Yeah, there's a problem, but I'd say it's an incredibly minor failure when compared to not having incremental backups at all. I've sometimes gone for several backup cycles before realizing anything was wrong, so it would be difficult to convince me they're not worthwhile.
Do you have a real-world example where this might happen? The best I've got is moving messages in Cyrus IMAP - if they were both placed in the same second and have the same length, and you moved one away and the other into its folder before any other mail arrived there, I guess this would happen. I just consider that sequence pretty unlikely, and the consequences not too severe.
It is very unlikely, yes. I know incremental backups can be very handy, so it's perfectly logical people find it's worth the "risk". I don't know of any concrete significant real world examples, I just don't like situations where the theory shows that the backup may miss files.
I know it's kind of an extreme example, but would you go up in an airliner of which you know the software would crash at certain speed, angle and fullconsumption combination?
OK, my slashdot noobness is revealed. Here's the post again...
"I think his complaints are no longer relevant. rdiff-backup has a --compare-hash option, though I haven't checked the details. Maybe the author should give it another look.. "
The hash is stored in the meta information, and the compare option does only that, comparing the live system to your archive. It does not say anything about the change-detection behaviour used during a backup.
"Besides, if you have an accurate timeserver (you should! time is unbelievably important to software in general!), the timestamp check is pretty safe, barring maliciousness. And if your machine has been compromised, the data coming off it should not be trusted in general. This is just one more case of that."
No, it's not (safe, I mean). Do this:
touch a b edit a and b to be the same length but different content stat a b mv b a stat a a will now have the mtime b had first. mtime+size is not changed, file is not backed up.
This is a danger in my opinion.
"Have you looked at brackup? It seems promising, anyway, but I haven't actually tried it. Maybe when it's a little more mature..."
No, I will have a look. But as I said a few posts below, I'll have to go to sleep now:)
[quote]I think his complaints are no longer relevant. rdiff-backup has a --compare-hash option, though I haven't checked the details. Maybe the author should give it another look...[/quote]
The hash is stored in the meta information, and the compare option does only that, comparing the live system to your archive. It does not say anything about the change-detection behaviour used during a backup.
[quote]Besides, if you have an accurate timeserver (you should! time is unbelievably important to software in general!), the timestamp check is pretty safe, barring maliciousness. And if your machine has been compromised, the data coming off it should not be trusted in general. This is just one more case of that.[/quote]
No, it's not (safe, I mean). Do this:
touch a b
edit a and b to be the same length but different content
stat a b
mv b a
stat a
a will now have the mtime b had first. mtime+size is not changed, file is not backed up.
This is a danger in my opinion.
[quote]Have you looked at brackup? It seems promising, anyway, but I haven't actually tried it. Maybe when it's a little more mature...[/quote]
No, I will have a look. But as I said a few posts below, I'll have to go to sleep now:)
Oh, one more thing, encryption. I was in doubt whether to include it or not. I use different encryption schemes for my backups (LUKS for external HD and GPG for DVD burning), but I decided this can be left to the reader. I may include a chapter on it, after all.
A quick reply from the author of the article before I go to sleep:
About dump. So, that's a freebsd command? I've always suspected it existed, doing the very thing the man page described, because of the dump field in/etc/fstab. But I have never actually seen a machine which had the dump command... It's possibly not very safe BTW. If it works like DOS's Archive bit, than it can't be trusted: it can be set manually. Some DOS apps even used them as copy protection mechanism...
The suggestions (for software and the rest). The comments are very much appreciated. I'll investigate them and adjust the article accordingly. For now, I have to sleep:)
Slashdot Mirror
Second language mistake (frame vs chassis) and profanity aside, I still can't confirm the 100% thing. [1] is interesting though. Still not 'almost 100%', but the truth is, as usual, somewhere in the middle. [1] http://www.worldautosteel.org/...
Do you have a source for your 100% recycling claims? I know people who worked with the car recycling industry, and they said quite the opposite. Recycled steal isn't allowed in the frames. and recycling is dang hard, not to mention an afterthought. They smash the car to bits and use eddy-current separation to get the metals, but that is by no means pure.
I tried disabling it, and immediately got calls from people that 'a trust relationship can't be established with the central logon server' or some such thing when they tried to log in.
An iPad, seriosly...? iPads are media consumption devices, not workplace tools, unless of course FB, NetFlix and YouTube are what you do at work.
This little hidden comment may only have a score of 2 (currently), but it's a gem. I now can formulate my view of tablets in words instead of grunts :)
Seeing as how I remembered my Win95 (20 chars) and Win98 (25 chars) serial keys just from reinstalling every two months, I think I would remember that password quite quickly, having to type it every day. I actually still know those serials...
Depends on the situation. If you're restoring from another system, such as a live CD, --numeric-owner is vital, or users can be messed up. All the GIDs en UIDs of the system you're using to restore are not identical to the ones of the system your restore. Therefore, name matching by string is not reliable.
Rdiff-backup uses mtime+size as a unique identifier. The author tried using ctime, but there were problems with that. Unfortunately, he couldn't remember what they were... Ben Escoto (the author) told me so personally.
I don't have any official "credentials"... When I talk about machines, I mean Linux machines. I should clarify the intro about that (the word "mostly" should be removed). Debian, Slackware, Gentoo didn't have it, per default.
But I don't need crediantials to let this article be useful to anybody, I would say. People can agree or disagree with the points I make of their own accord.
You also have to specify --numeric-owner...
I put it on my TODO list to check out, Mondoarchive I mean.
Actually, I burn them to DVDs. But, I don't really have one specific target audience in mind. Large enterprise setups require more work and more specific apps, of course. I didn't know of Amanda, but I have it on my TODO.
As I stated in the intro, my experience is with Linux (perhaps I should remove the word "mostly" ...). The lack of dump on Linux can be blaimed for my ignorance. But, I will investigate it, of course.
Stupid me, there simply a linux package available... I'll check it out.
The hash information feature was included after I suggested a feature for hash-change-checking. The hash is already stored, because that was easy to do, but the change checking never got implemented.
It is very unlikely, yes. I know incremental backups can be very handy, so it's perfectly logical people find it's worth the "risk". I don't know of any concrete significant real world examples, I just don't like situations where the theory shows that the backup may miss files.
I know it's kind of an extreme example, but would you go up in an airliner of which you know the software would crash at certain speed, angle and fullconsumption combination?
OK, my slashdot noobness is revealed. Here's the post again...
:)
"I think his complaints are no longer relevant. rdiff-backup has a --compare-hash option, though I haven't checked the details. Maybe the author should give it another look.. "
The hash is stored in the meta information, and the compare option does only that, comparing the live system to your archive. It does not say anything about the change-detection behaviour used during a backup.
"Besides, if you have an accurate timeserver (you should! time is unbelievably important to software in general!), the timestamp check is pretty safe, barring maliciousness. And if your machine has been compromised, the data coming off it should not be trusted in general. This is just one more case of that."
No, it's not (safe, I mean). Do this:
touch a b
edit a and b to be the same length but different content
stat a b
mv b a
stat a
a will now have the mtime b had first. mtime+size is not changed, file is not backed up.
This is a danger in my opinion.
"Have you looked at brackup? It seems promising, anyway, but I haven't actually tried it. Maybe when it's a little more mature..."
No, I will have a look. But as I said a few posts below, I'll have to go to sleep now
[quote]I think his complaints are no longer relevant. rdiff-backup has a --compare-hash option, though I haven't checked the details. Maybe the author should give it another look...[/quote] The hash is stored in the meta information, and the compare option does only that, comparing the live system to your archive. It does not say anything about the change-detection behaviour used during a backup. [quote]Besides, if you have an accurate timeserver (you should! time is unbelievably important to software in general!), the timestamp check is pretty safe, barring maliciousness. And if your machine has been compromised, the data coming off it should not be trusted in general. This is just one more case of that.[/quote] No, it's not (safe, I mean). Do this: touch a b edit a and b to be the same length but different content stat a b mv b a stat a a will now have the mtime b had first. mtime+size is not changed, file is not backed up. This is a danger in my opinion. [quote]Have you looked at brackup? It seems promising, anyway, but I haven't actually tried it. Maybe when it's a little more mature...[/quote] No, I will have a look. But as I said a few posts below, I'll have to go to sleep now :)
Oh, one more thing, encryption. I was in doubt whether to include it or not. I use different encryption schemes for my backups (LUKS for external HD and GPG for DVD burning), but I decided this can be left to the reader. I may include a chapter on it, after all.
Hi there,
/etc/fstab. But I have never actually seen a machine which had the dump command... It's possibly not very safe BTW. If it works like DOS's Archive bit, than it can't be trusted: it can be set manually. Some DOS apps even used them as copy protection mechanism...
:)
A quick reply from the author of the article before I go to sleep:
About dump. So, that's a freebsd command? I've always suspected it existed, doing the very thing the man page described, because of the dump field in
The suggestions (for software and the rest). The comments are very much appreciated. I'll investigate them and adjust the article accordingly. For now, I have to sleep