[opensuse] Backup .. restore ... access/ownership
I've just been though the tedious process of restoring from backup. The 1T WD drive developed more unmappable bad sectors than it could handle, right in my /home partition! Bathtub so replaced under warranty. Tedium of doing reinstall. Previously /home had been backed up rsync to thumb-drive :-) Rsync out; rsync back in :-) It was then the task of restoring the ~/Documents, ~/Mail, ~/Music etc from DVD. Mount as /mnt/dvd then rsync into place. Step-and-repeat. I'd been a good boy and done my backups :-) OUCH! For some reason everything seemed to be r--r--r-- root.root I'd burnt the DVDs with K3B. Is this some side effect of putting a reiserFS on a DVD using K3B in data mode? Or what? Any thoughts? -- Think of managing change as an adventure. It tests your skills and abilities. It brings forth talent that may have been dormant. Change is also a training ground for leadership. When we think of leaders, we remember times of change, innovation and conflict. Leadership is often about shaping a new way of life. To do that, you must advance change, take risks and accept responsibility for making change happen. - Charles E. Rice, CEO of Barnett Bank -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 28 Mar 2014 21:28:00 -0400 Anton Aylward wrote:
OUCH! For some reason everything seemed to be r--r--r-- root.root
I'd burnt the DVDs with K3B. Is this some side effect of putting a reiserFS on a DVD using K3B in data mode? Or what?
Hi Anton, You've asked for thoughts, so... I think there are two separate 'gotchas' here. First, I don't think the original filesystem type is at play. I think the backup media being ROM is what caused the files to be marked read-only as they were written. Second, I think if you'd mounted the DVDs so they were owned by you (e.g. anton.users) instead of by root (root.root) your files would have inherited that ownership as they were being read. Third, I think if I were backing up to DVD, I'd first compress the source directories into a tarball to preserve the original attributes. I could be wrong, but these are my initial thoughts... hth & YMMV etc. etc. regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/28/2014 10:28 PM, Carl Hartung pecked at the keyboard and wrote:
On Fri, 28 Mar 2014 21:28:00 -0400 Anton Aylward wrote:
OUCH! For some reason everything seemed to be r--r--r-- root.root
I'd burnt the DVDs with K3B. Is this some side effect of putting a reiserFS on a DVD using K3B in data mode? Or what?
Hi Anton,
You've asked for thoughts, so... I think there are two separate 'gotchas' here.
First, I don't think the original filesystem type is at play. I think the backup media being ROM is what caused the files to be marked read-only as they were written.
Second, I think if you'd mounted the DVDs so they were owned by you (e.g. anton.users) instead of by root (root.root) your files would have inherited that ownership as they were being read.
Third, I think if I were backing up to DVD, I'd first compress the source directories into a tarball to preserve the original attributes.
I could be wrong, but these are my initial thoughts... hth & YMMV etc. etc.
regards,
Carl
I agree with Carl, if you did your backup on a file by file basis that you have lost all of the file attributes. I always create a tar file of the filesystem and then backup the tar file to DVD, that way you don't lose the attributes. Ken -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-29 03:44, Ken Schneider - openSUSE wrote:
On 03/28/2014 10:28 PM, Carl Hartung pecked at the keyboard and wrote:
I agree with Carl, if you did your backup on a file by file basis that you have lost all of the file attributes. I always create a tar file of the filesystem and then backup the tar file to DVD, that way you don't lose the attributes.
Wait. You can keep all Linux filesystem attributes on a cdrom, if you use the appropriate options. You need to activate the Rock Ridge extensions, not Joliet (or both). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, 29 Mar 2014 04:01:56 +0100 Carlos E. R. wrote:
On 2014-03-29 03:44, Ken Schneider - openSUSE wrote:
On 03/28/2014 10:28 PM, Carl Hartung pecked at the keyboard and wrote:
I agree with Carl, if you did your backup on a file by file basis that you have lost all of the file attributes. I always create a tar file of the filesystem and then backup the tar file to DVD, that way you don't lose the attributes.
Wait. You can keep all Linux filesystem attributes on a cdrom, if you use the appropriate options.
You need to activate the Rock Ridge extensions, not Joliet (or both).
Ah, of course ... thanks for reminding us, Carlos. It's been several years since I last did any serious backups to CD/DVD so I guess I'd forgotten. That being said, I seem to recall also compressing first to reduce the number of disks I was burning and this, coincidentally, also served to preserve the attributes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-29 04:12, Carl Hartung wrote:
On Sat, 29 Mar 2014 04:01:56 +0100
You need to activate the Rock Ridge extensions, not Joliet (or both).
Ah, of course ... thanks for reminding us, Carlos. It's been several years since I last did any serious backups to CD/DVD so I guess I'd forgotten. That being said, I seem to recall also compressing first to reduce the number of disks I was burning and this, coincidentally, also served to preserve the attributes.
Compression... well, not really the compression part, but the archiving part. When in the Unix/Linux world you create an archive, like a 'tar', the attributes and permissions are stored inside the archive. Thus, when you copy the archive, compressed or not, to a CD or tape or HD, they are preserved. I personally dislike compressed tars for backups. A single byte error in the media, and you can not decompress it. The entire tar archive is lost. Very unreliable. There is a compression extension for CD/DVDs. The DVD can be mounted normally, and the contents are transparently decompressed on the fly, so you get direct access to any files in there. However, the process of creating a compressed DVD is cumbersome. Look up the -z parameter in the "genisoimage" man page (old mkisofs). -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, 29 Mar 2014 04:21:41 +0100 Carlos E. R. wrote:
I personally dislike compressed tars for backups. A single byte error in the media, and you can not decompress it. The entire tar archive is lost. Very unreliable.
In my case, the issue is moot, but I never lost an archive due to the issues you've raised here. There's not only faulty / degraded media to worry about, but there are varying calibrations / alignments across optical drives. The potential for catastrophic loss definitely exists. In fact, I actually think this is why I stopped using CD/DVD media for backups. I switched to running all my backups to redundant external hard drives. This method means at all times I have at least three copies of everything critical ... the 'live' filesystem originals plus two physically separate 'mirrors' (rsync.) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/29/2014 12:17 AM, Carl Hartung wrote:
On Sat, 29 Mar 2014 04:21:41 +0100 Carlos E. R. wrote:
I personally dislike compressed tars for backups. A single byte error in the media, and you can not decompress it. The entire tar archive is lost. Very unreliable.
In my case, the issue is moot, but I never lost an archive due to the issues you've raised here. There's not only faulty / degraded media to worry about, but there are varying calibrations / alignments across optical drives. The potential for catastrophic loss definitely exists. In fact, I actually think this is why I stopped using CD/DVD media for backups. I switched to running all my backups to redundant external hard drives. This method means at all times I have at least three copies of everything critical ... the 'live' filesystem originals plus two physically separate 'mirrors' (rsync.)
Looking at the price of bulk thumbdrives from China, in the order of $10 each for 256G quantity 50 to 400, that's a very viable alternative .... If you can afford to amortise the bulk purchase somehow. Corporate its easy to spread the cost, but for individuals that's another matter. Historically I've tried doing this with the local "computer club" in various guises, up to back in the 1980s, getting a leased line internet connection for the local UNIX Users Group. The "if you're so smart" reaction pizzed me off so I did it and got no support, only criticism from the group (including mailbombing) so I made it a commercial venture to cover cost and found it was profitable. Maybe I should go into the business of selling thumbdrives? Would you buy one, James? -- "Combinatorics -- how to count without counting." -- Cassablanca -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Would you buy one, James?
I've already got lots of USB storage available. My largest is 500 GB, but I see terabyte external drives are well under $100. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carl Hartung wrote:
Ah, of course ... thanks for reminding us, Carlos. It's been several years since I last did any serious backups to CD/DVD so I guess I'd forgotten. That being said, I seem to recall also compressing first to reduce the number of disks I was burning and this, coincidentally, also served to preserve the attributes.
This is getting all too complex. Mebe we should go back to 9 track tapes and use tar the way it was intended. ;-) I just back up to a hard drive with cp -a, which works fine. The attributes are preserved and I can easily mount the drive to access all the files. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 30 Mar 2014 08:30:36 -0400 James Knott wrote:
This is getting all too complex. Mebe we should go back to 9 track tapes and use tar the way it was intended. ;-)
Please, at least give us DLTs, James! :-)
I just back up to a hard drive with cp -a, which works fine. The attributes are preserved and I can easily mount the drive to access all the files.
I use rsync for basically the same reason but my objective is to be able to install the replacement drive and be up and running again in a matter of minutes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carl Hartung wrote:
I just back up to a hard drive with cp -a, which works fine. The
attributes are preserved and I can easily mount the drive to access all the files. I use rsync for basically the same reason but my objective is to be able to install the replacement drive and be up and running again in a matter of minutes.
When copying to an empty partition, rsync provides no advantage over cp -a. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 30/03/2014 16:22, Carlos E. R. a écrit :
It can verify the copy,
is this default, I don't understand the manpage? thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 16:27, jdd wrote:
Le 30/03/2014 16:22, Carlos E. R. a écrit :
It can verify the copy,
is this default, I don't understand the manpage?
No, not default. The default is only to verify the timestamp, size, permissions... I use "--checksum", IIRC the option. And it is CPU intensive and slow. I'm unsure of the performance implications if done over a remote source, which can be via ssh or via rsync daemon. If you are using XFS partitions, there are very fast applications for backup/restore. You can either dump an image, or a file copy. Speed is impressive, but there is no verification. What I do then is use xfs tools to do the initial copy, then an rsync verification run. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 30/03/2014 16:39, Carlos E. R. a écrit :
On 2014-03-30 16:27, jdd wrote:
Le 30/03/2014 16:22, Carlos E. R. a écrit :
It can verify the copy,
is this default, I don't understand the manpage?
No, not default.
The default is only to verify the timestamp, size, permissions... I use "--checksum", IIRC the option.
I din't think so. look at the man page: -c, --checksum This chan(...) Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option’s before-the-transfer "Does this file need to be updated?" check. what I understand is that checksum *during the transfer* is always done
If you are using XFS partitions, there are very fast applications for backup/restore. You can either dump an image, or a file copy. Speed is impressive, but there is no verification. What I do then is use xfs tools to do the initial copy, then an rsync verification run.
btrfs is said 1) to be next suse default, 2) have the same or similar option, I yet have to understand how this works on restore :-) thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 17:28, jdd wrote:
Le 30/03/2014 16:39, Carlos E. R. a écrit :
I din't think so. look at the man page:
-c, --checksum This chan(...)
Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option’s before-the-transfer "Does this file need to be updated?" check.
Ah, yes, right. It makes sense, as rsync can be used to repair a badly transferred file, like a huge DVD iso file, without resending it complete.
what I understand is that checksum *during the transfer* is always done
True. It is probably an overkill. And I do it twice, so double overkill :-)
If you are using XFS partitions, there are very fast applications for backup/restore. You can either dump an image, or a file copy. Speed is impressive, but there is no verification. What I do then is use xfs tools to do the initial copy, then an rsync verification run.
btrfs is said 1) to be next suse default, 2) have the same or similar option, I yet have to understand how this works on restore :-)
No idea. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-03-30 16:44, James Knott wrote:
jdd wrote:
I don't understand the manpage?
Man pages are meant to be incoherent to all but "experts". You have to already know the answer before you use man. ;-)
LOL! Yes. There are some exceptions, though. Fetchmail or procmail, for instance. They have useful examples. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/30/2014 11:15 AM, Carlos E. R. wrote:
On 2014-03-30 16:44, James Knott wrote:
jdd wrote:
I don't understand the manpage?
Man pages are meant to be incoherent to all but "experts". You have to already know the answer before you use man. ;-)
LOL! Yes.
There are some exceptions, though. Fetchmail or procmail, for instance. They have useful examples.
... For beginners. -- We know nothing about motivation. All we can do is write books about it. --Peter F. Drucker -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 17:18, Anton Aylward wrote:
On 03/30/2014 11:15 AM, Carlos E. R. wrote:
On 2014-03-30 16:44, James Knott wrote:
jdd wrote:
I don't understand the manpage?
Man pages are meant to be incoherent to all but "experts". You have to already know the answer before you use man. ;-)
LOL! Yes.
There are some exceptions, though. Fetchmail or procmail, for instance. They have useful examples.
... For beginners.
At some point, it is always the first time you have to setup some program and first time read the manual... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
When copying to an empty partition, rsync provides no advantage over cp -a. It does.
It can verify the copy, or retake an interrupted transfer.
Given that we're normally copying to a directly attached drive, how often do those problems show up? How is copying any different than any other write in this regard. There are already error detection/correction methods in use. Even when copying over a network, there are mechanisms in TCP & Ethernet to detect & correct errors. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 16:42, James Knott wrote:
Carlos E. R. wrote:
When copying to an empty partition, rsync provides no advantage over cp -a. It does.
It can verify the copy, or retake an interrupted transfer.
Given that we're normally copying to a directly attached drive, how often do those problems show up? How is copying any different than any other write in this regard. There are already error detection/correction methods in use. Even when copying over a network, there are mechanisms in TCP & Ethernet to detect & correct errors.
Which fail. http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows... www.streamscale.com/media/pdf_folder/CERN_Data_Corruption.pdf http://research.google.com/archive/disk_failures.pdf -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sun, 30 Mar 2014 16:53:11 +0200 Carlos E. R. wrote:
On 2014-03-30 16:42, James Knott wrote:
Carlos E. R. wrote:
When copying to an empty partition, rsync provides no advantage over cp -a. It does.
It can verify the copy, or retake an interrupted transfer.
Given that we're normally copying to a directly attached drive, how often do those problems show up? How is copying any different than any other write in this regard. There are already error detection/correction methods in use. Even when copying over a network, there are mechanisms in TCP & Ethernet to detect & correct errors.
Which fail.
http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows...
www.streamscale.com/media/pdf_folder/CERN_Data_Corruption.pdf
:-) You forgot this one: http://en.wikipedia.org/wiki/Murphy%27s_law In my experience, there seems to be an inverse relationship between how critical one's data is and how long it can hang around uncorrupted and undisturbed. The more important it is, the more frequently you should be backing it up. IOW, frequent and redundant backups -- serving both archival and operational needs -- is for all practical purposes the only defense. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 17:16, Carl Hartung wrote:
On Sun, 30 Mar 2014 16:53:11 +0200 Carlos E. R. wrote:
:-) You forgot this one: http://en.wikipedia.org/wiki/Murphy%27s_law
LOL, yes.
In my experience, there seems to be an inverse relationship between how critical one's data is and how long it can hang around uncorrupted and undisturbed.
I managed to corrupt both the original and backup copies of a paper, in different floppies, that I had to hand to my teacher for examination, hours before the time limit. Yes, I know about Murphy...
The more important it is, the more frequently you should be backing it up. IOW, frequent and redundant backups -- serving both archival and operational needs -- is for all practical purposes the only defense.
The first link explains an interesting feature of btrfs native raid, however it is called. It can automatically repair a file with errors. Traditional raid can not. I'd like a similar repair capability self contained in normal files, without the need for raid type structures (double or triple hardware). Just with "forward recovery data" could work. At least on (long term) backups. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 30/03/2014 17:16, Carl Hartung a écrit :
be backing it up. IOW, frequent and redundant backups -- serving both archival and operational needs -- is for all practical purposes the only defense.
redundency is the key, but do not think you wont ever loose data :-(. Be prepared said young boys once :-) my last recent example is using unison (http://www.cis.upenn.edu/~bcpierce/unison/) in goal of having real udentical disks (with two work location and a shuttle disk). I ended with two disks full of zero size files!!! happy I had a redundency third copy :-) probable reason (?) the new hard drive was failing after one week use :-(. But it's not the first time I experienced that, and it's really dangerous: is some part of your disk fails silently you may well have copied each time the zeroed file!! good dvd or Blu-Ray can't be zeroed by software :-) - but they can by other mean, randomly jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carl Hartung wrote:
In my experience, there seems to be an inverse relationship between how critical one's data is and how long it can hang around uncorrupted and undisturbed. The more important it is, the more frequently you should be backing it up. IOW, frequent and redundant backups -- serving both archival and operational needs -- is for all practical purposes the only defense.
I recall the days when the night shift computer operator would start their shift with a bunch of mag tapes, ready to do the nightly backups. Two copies were made, one stored off site. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 30 Mar 2014 09:41:20 -0400 James Knott wrote:
Carl Hartung wrote:
I just back up to a hard drive with cp -a, which works fine. The
attributes are preserved and I can easily mount the drive to access all the files. I use rsync for basically the same reason but my objective is to be able to install the replacement drive and be up and running again in a matter of minutes.
When copying to an empty partition, rsync provides no advantage over cp -a.
I understand, but emptying a partition only to run a more current snapshot is -- at the very least -- highly inefficient. Amongst my backup drives is one that is kept as a literal drop-in replacement. When the original needs to be taken out of service, I just drop in the replacement and I'm up and running in a matter of minutes. rsync makes this possible. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carl Hartung wrote:
I understand, but emptying a partition only to run a more current snapshot is -- at the very least -- highly inefficient.
I guess I was thinking partition because I recently moved my system to a new drive. I often back up to a new directory on an external drive. I name the directory with the name of the original system and date. I currently have 3 or 4 backups on my 500 GB drive. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 14:30, James Knott wrote:
This is getting all too complex. Mebe we should go back to 9 track tapes and use tar the way it was intended. ;-)
Wait till you get a scratch on that tape. If you used compressed tar, the entire tape is useless.
I just back up to a hard drive with cp -a, which works fine. The attributes are preserved and I can easily mount the drive to access all the files.
And then you can get a transmission error, and one file gets a corrupted byte. On some type of files, like a jpeg photo, it is almost destroyed. Have a look at this link, there is an example of what happens when a single bit (bit, not even byte) changes in a jpeg. http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows... For doing backups, you have to compare source with copy after done. At least, a checksum compare. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/28/2014 11:01 PM, Carlos E. R. wrote:
On 2014-03-29 03:44, Ken Schneider - openSUSE wrote:
On 03/28/2014 10:28 PM, Carl Hartung pecked at the keyboard and wrote:
I agree with Carl, if you did your backup on a file by file basis that you have lost all of the file attributes. I always create a tar file of the filesystem and then backup the tar file to DVD, that way you don't lose the attributes.
Wait. You can keep all Linux filesystem attributes on a cdrom, if you use the appropriate options.
You need to activate the Rock Ridge extensions, not Joliet (or both).
IIR This batch was done with RR not J. I've had problems with J before, re-naming files, converting " " to "_"[1] and other nonsense like that. [1] nasty when you have both "file_long_name" and "file long name" -- The art of leading, in operations large or small, is the art of dealing with humanity, of working diligently on behalf of men, of being sympathetic with them, but equally, of insisting that they make a square facing toward their own problems. - S. L. A. Marshall Men Against Fire -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-29 12:49, Anton Aylward wrote:
On 03/28/2014 11:01 PM, Carlos E. R. wrote:
Wait. You can keep all Linux filesystem attributes on a cdrom, if you use the appropriate options.
You need to activate the Rock Ridge extensions, not Joliet (or both).
IIR This batch was done with RR not J.
Weird. Maybe k3b did something strange? I haven't done this in long time.
I've had problems with J before, re-naming files, converting " " to "_"[1] and other nonsense like that.
[1] nasty when you have both "file_long_name" and "file long name"
True. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-03-29 17:17, Carlos E. R. wrote:
On 2014-03-29 12:49, Anton Aylward wrote:
On 03/28/2014 11:01 PM, Carlos E. R. wrote:
Wait. You can keep all Linux filesystem attributes on a cdrom, if you use the appropriate options.
You need to activate the Rock Ridge extensions, not Joliet (or both).
IIR This batch was done with RR not J.
Weird. Maybe k3b did something strange? I haven't done this in long time.
I'm trying it now. In properties of the project go to the filesystem tab, select "rock ridge". Then and click on "custom" and click on "preserve file permissions (backup)" .
I've had problems with J before, re-naming files, converting " " to "_"[1] and other nonsense like that.
[1] nasty when you have both "file_long_name" and "file long name"
True.
I made a test. This is the original tree: cer@Telcontar:~> tree -a -p -u -g -s -h k3b_test k3b_test ├── [-rw-r--r-- cer users 0] .pepe ├── [-rw-r--r-- cer users 960] En un lugar ├── [-rw-r--r-- cer users 0] En un lugar~ ├── [-rw-r--r-- cer users 0] España ├── [-rw-r--r-- cer users 0] José ├── [-rw-r--r-- cer users 0] juan ├── [-rw-r--r-- cer users 0] long------------------------------------------------------------------------------------------------------------------------------------------------------------------------name ├── [-rw-r--r-- cer users 0] pe#pe ├── [-rw-r--r-- cer users 0] pe....pe ├── [-rw-r--r-- cer2 users 0] pePE ├── [-rw-r--r-- cer users 0] pepe ├── [-rw-r--r-- cer users 0] pepe. ├── [-rw------- cer users 0] pepe2 ├── [-rw-r--r-- cer users 0] pepe~ ├── [drwxr-xr-x cer users 17] test 1 │ └── [-rw-r--r-- cer users 0] pepe └── [drwxr-xr-x cer users 17] test_1 └── [-rw-r--r-- cer users 0] pepe and this is the tree on the mounted cd: cer@Telcontar:~> tree -a -p -u -g -s -h k3b_test_mount/ k3b_test_mount/ └── [drwxr-xr-x cer users 4.0K] k3b_test ├── [-rw-r--r-- cer users 0] .pepe ├── [-rw-r--r-- cer users 960] En un lugar ├── [-rw-r--r-- cer users 0] En un lugar~ ├── [-rw-r--r-- cer users 0] España ├── [-rw-r--r-- cer users 0] José ├── [-rw-r--r-- cer users 0] juan ├── [-rw-r--r-- cer users 0] long------------------------------------------------------------------------------------------------------------------------------------------------------------------------name ├── [-rw-r--r-- cer users 0] pe#pe ├── [-rw-r--r-- cer users 0] pe....pe ├── [-rw-r--r-- cer2 users 0] pePE ├── [-rw-r--r-- cer users 0] pepe ├── [-rw-r--r-- cer users 0] pepe. ├── [-rw------- cer users 0] pepe2 ├── [-rw-r--r-- cer users 0] pepe~ ├── [drwxr-xr-x cer users 2.0K] test 1 │ └── [-rw-r--r-- cer users 0] pepe └── [drwxr-xr-x cer users 2.0K] test_1 └── [-rw-r--r-- cer users 0] pepe 3 directories, 16 files cer@Telcontar:~> As you see, there is a file owned by another user, not all have the same permission set, there are files with different case, names with a space or an underscore, strange chars, very long names... -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/29/2014 12:55 PM, Carlos E. R. wrote:
and this is the tree on the mounted cd:
And how did you mount that? Back to the "only root can do that" problem! I suspect that when the files are root.root and you chown/chgrp it has some side effect on the permissions. Just a memory but I can't find this documented. -- "The Singapore government isn't interested in controlling information, but wants a gradual phase-in of services to protect ourselves. It's not to control, but to protect the citizens of Singapore. In our society, you can state your views, but they have to be correct." -- Ernie Hai, coordinator of the Singapore Government Internet Project -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 30/03/2014 03:49, Anton Aylward a écrit :
On 03/29/2014 12:55 PM, Carlos E. R. wrote:
and this is the tree on the mounted cd:
And how did you mount that? Back to the "only root can do that" problem!
I suspect that when the files are root.root and you chown/chgrp it has some side effect on the permissions. Just a memory but I can't find this documented.
AFAIR there is a solution around fuse, but I don't had problem mounting a dvd as user recently jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/30/2014 03:09 AM, jdd wrote:
Le 30/03/2014 03:49, Anton Aylward a écrit :
On 03/29/2014 12:55 PM, Carlos E. R. wrote:
and this is the tree on the mounted cd:
And how did you mount that? Back to the "only root can do that" problem!
I suspect that when the files are root.root and you chown/chgrp it has some side effect on the permissions. Just a memory but I can't find this documented.
AFAIR there is a solution around fuse, but I don't had problem mounting a dvd as user recently
Do you have an entry in your /etc/fstab specifically for the DVD? -- The only freedom which deserves the name, is that of pursuing our own good in our own way, so long as we do not attempt to deprive others of theirs, or impede their efforts to obtain it. --John Stuart Mill (On Liberty, 1859) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 30/03/2014 14:11, Anton Aylward a écrit :
Do you have an entry in your /etc/fstab specifically for the DVD?
no and I just tested an old cd, it's mounted on, /var/run/media/jdd/CDROM/ by the kde widget jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 03:49, Anton Aylward wrote:
On 03/29/2014 12:55 PM, Carlos E. R. wrote:
and this is the tree on the mounted cd:
And how did you mount that? Back to the "only root can do that" problem!
Because I used "su", obviously :-) However, you can mount a dvd or iso archive with 'mc', as user. It does not matter who mounts the media, the result is the same because this type of CD stores the proper ownership data. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/28/2014 10:28 PM, Carl Hartung wrote:
On Fri, 28 Mar 2014 21:28:00 -0400 Anton Aylward wrote:
OUCH! For some reason everything seemed to be r--r--r-- root.root
I'd burnt the DVDs with K3B. Is this some side effect of putting a reiserFS on a DVD using K3B in data mode? Or what?
Hi Anton,
You've asked for thoughts, so... I think there are two separate 'gotchas' here.
First, I don't think the original filesystem type is at play. I think the backup media being ROM is what caused the files to be marked read-only as they were written.
I'm compelled by the evidence to agree with you on this point.
Second, I think if you'd mounted the DVDs so they were owned by you (e.g. anton.users) instead of by root (root.root) your files would have inherited that ownership as they were being read.
When I tried doing "mount /dev/sr0 /mnt/dvd" I got the message "Only root can do that". Resistance is futile!
Third, I think if I were backing up to DVD, I'd first compress the source directories into a tarball to preserve the original attributes.
Ah. OK. I'll need to expand my /tmp so I can tar up a 4G partition to put it on a 5G DVD then. I've managed to arrange much of my stuff under /home in 5G partitions :-) I try to make sure they don't fill up :-) So far I'm not at "Music_A-N" & "Music_M-Z" but one never knows ...
I could be wrong, but these are my initial thoughts... hth & YMMV etc. etc.
regards,
Carl
-- The leader has to be practical and a realist, yet must talk the language of the visionary and the idealist. - Eric Hoffer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [03-29-14 07:48]:
On 03/28/2014 10:28 PM, Carl Hartung wrote: [...]
First, I don't think the original filesystem type is at play. I think the backup media being ROM is what caused the files to be marked read-only as they were written.
I'm compelled by the evidence to agree with you on this point.
Second, I think if you'd mounted the DVDs so they were owned by you (e.g. anton.users) instead of by root (root.root) your files would have inherited that ownership as they were being read.
When I tried doing "mount /dev/sr0 /mnt/dvd" I got the message "Only root can do that".
Resistance is futile!
In *this* instance, "only root can do that", but you are free, depending on mount permissions, to access/read/write/execute as <user>. Resistance noted is *security* :^) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/29/2014 07:56 AM, Patrick Shanahan wrote:
* Anton Aylward <opensuse@antonaylward.com> [03-29-14 07:48]:
On 03/28/2014 10:28 PM, Carl Hartung wrote: [...]
First, I don't think the original filesystem type is at play. I think the backup media being ROM is what caused the files to be marked read-only as they were written.
I'm compelled by the evidence to agree with you on this point.
Second, I think if you'd mounted the DVDs so they were owned by you (e.g. anton.users) instead of by root (root.root) your files would have inherited that ownership as they were being read.
When I tried doing "mount /dev/sr0 /mnt/dvd" I got the message "Only root can do that".
Resistance is futile!
In *this* instance, "only root can do that", but you are free, depending on mount permissions, to access/read/write/execute as <user>. Resistance noted is *security* :^)
Oh, yes, I did run the rsync extract as "anton" and got unreadable errors since the DVD was mounted as root and all the files were, as I said, root.root. Some were r-------- of course since they had originally been "anton.users rw-------", (or in a couple of cases "dovecot.mail rw-r-----") But, as I said, this all got flattened to read only. -- Perhaps I am a dinosaur, but if I saw the word "hacker" used positively on a resume, I would have trouble continuing. Hacking means using "quick and dirty" means to achieve an objective without concern for "collateral damage" and is totally opposite to my philosophy of "first, do no harm". -- Pagett Peterson, Wednesday, January 18, 2006 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 29/03/2014 13:04, Anton Aylward a écrit :
But, as I said, this all got flattened to read only.
iy's not common, but you can format a dvd as ext3 - in fact, create the iso in advance, format it ext3, copy the data and write the iso. as this is only usefull for system backup it's not that difficult and restoring is easy jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-29 13:17, jdd wrote:
Le 29/03/2014 13:04, Anton Aylward a écrit :
But, as I said, this all got flattened to read only.
iy's not common, but you can format a dvd as ext3 - in fact, create the iso in advance, format it ext3, copy the data and write the iso.
Yes, I do that, but using XFS. Ext3 wastes more space in metadata. You can even use LUKS encryption. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 29/03/14 11:46, Anton Aylward wrote:
Ah. OK. I'll need to expand my /tmp so I can tar up a 4G partition to put it on a 5G DVD then. I've managed to arrange much of my stuff under /home in 5G partitions :-)
How many partitions do you have under your home directory?
I try to make sure they don't fill up :-) So far I'm not at "Music_A-N" & "Music_M-Z" but one never knows ...
I couldn't even fit "Music_A" in 5G... Dylan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/29/2014 07:58 AM, Dylan wrote:
On 29/03/14 11:46, Anton Aylward wrote:
Ah. OK. I'll need to expand my /tmp so I can tar up a 4G partition to put it on a 5G DVD then. I've managed to arrange much of my stuff under /home in 5G partitions :-)
How many partitions do you have under your home directory?
I try to make sure they don't fill up :-) So far I'm not at "Music_A-N" & "Music_M-Z" but one never knows ...
I couldn't even fit "Music_A" in 5G...
No doubt I'll get there too as I feed more of my vinyl through. -- In the beginning was The Word and The Word was Content-type: text/plain -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-29 12:46, Anton Aylward wrote:
On 03/28/2014 10:28 PM, Carl Hartung wrote:
First, I don't think the original filesystem type is at play. I think the backup media being ROM is what caused the files to be marked read-only as they were written.
I'm compelled by the evidence to agree with you on this point.
See the test I just posted - from the cd: ├── [-rw-r--r-- cer2 users 0] pePE ├── [-rw-r--r-- cer users 0] pepe ├── [-rw-r--r-- cer users 0] pepe. ├── [-rw------- cer users 0] pepe2 They are "rw", and different users. And I used root to mount the CD. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, 29 Mar 2014 18:01:26 +0100 Carlos E. R. wrote:
On 2014-03-29 12:46, Anton Aylward wrote:
On 03/28/2014 10:28 PM, Carl Hartung wrote:
First, I don't think the original filesystem type is at play. I think the backup media being ROM is what caused the files to be marked read-only as they were written.
I'm compelled by the evidence to agree with you on this point.
See the test I just posted - from the cd:
├── [-rw-r--r-- cer2 users 0] pePE ├── [-rw-r--r-- cer users 0] pepe ├── [-rw-r--r-- cer users 0] pepe. ├── [-rw------- cer users 0] pepe2
They are "rw", and different users. And I used root to mount the CD.
This makes perfect sense because that's how the files were written during your test, where you specified 'backup' mode to preserve those attributes. I believe the 'norm' (not backup mode) causes files to be properly marked as read-only on read-only media. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-29 18:27, Carl Hartung wrote:
On Sat, 29 Mar 2014 18:01:26 +0100 Carlos E. R. wrote:
They are "rw", and different users. And I used root to mount the CD.
This makes perfect sense because that's how the files were written during your test, where you specified 'backup' mode to preserve those attributes. I believe the 'norm' (not backup mode) causes files to be properly marked as read-only on read-only media.
That's right. And it is the case, here, the subject of the thread says, it, backup-restore ;-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sat, 29 Mar 2014 22:11:19 +0100 Carlos E. R. wrote:
On 2014-03-29 18:27, Carl Hartung wrote:
On Sat, 29 Mar 2014 18:01:26 +0100 Carlos E. R. wrote:
They are "rw", and different users. And I used root to mount the CD.
This makes perfect sense because that's how the files were written during your test, where you specified 'backup' mode to preserve those attributes. I believe the 'norm' (not backup mode) causes files to be properly marked as read-only on read-only media.
That's right.
And it is the case, here, the subject of the thread says, it, backup-restore ;-)
This is a non sequitur, Carlos. I didn't dispute your test or question the subject. My contribution at the beginning of this thread was merely to explain to Anton how the files he'd backed up had lost their original ownerships and been made read-only. Your contribution has been to illustrate that there is a correct method for writing backups to CD/DVD-ROM. :-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-29 23:27, Carl Hartung wrote:
On Sat, 29 Mar 2014 22:11:19 +0100 Carlos E. R. wrote:
On 2014-03-29 18:27, Carl Hartung wrote:
On Sat, 29 Mar 2014 18:01:26 +0100 Carlos E. R. wrote:
They are "rw", and different users. And I used root to mount the CD.
This makes perfect sense because that's how the files were written during your test, where you specified 'backup' mode to preserve those attributes. I believe the 'norm' (not backup mode) causes files to be properly marked as read-only on read-only media.
That's right.
And it is the case, here, the subject of the thread says, it, backup-restore ;-)
This is a non sequitur, Carlos. I didn't dispute your test or question the subject. My contribution at the beginning of this thread was merely to explain to Anton how the files he'd backed up had lost their original ownerships and been made read-only. Your contribution has been to illustrate that there is a correct method for writing backups to CD/DVD-ROM. :-)
Ah, ok, I misunderstood, sorry. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 29/03/2014 22:11, Carlos E. R. a écrit :
And it is the case, here, the subject of the thread says, it, backup-restore ;-)
to keep this remark, every body knows any backup is unusefull is one can't test the restore (?). but how do you test this restore? For data it's pretty easy to restore in a temporary place, but for system? jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 30 Mar 2014 09:01:11 +0200 jdd jdd wrote:
but how do you test this restore? For data it's pretty easy to restore in a temporary place, but for system?
I'm sure there are more knowledgeable / sophisticated methods available but I just install the replacement drive and partition it (first 'dry run.') Then I restore, chroot in and run the bootloader installation. I use the same method to migrate installations to larger hard drives. On Sun, 30 Mar 2014 09:09:29 +0200 jdd jdd wrote:
Le 30/03/2014 03:49, Anton Aylward a écrit :
And how did you mount that? Back to the "only root can do that" problem!
AFAIR there is a solution around fuse, but I don't had problem mounting a dvd as user recently
I don't think this is germane. First, when you create the backup, you take care to preserve the original attributes. You must equally take care to preserve those attributes as the system is written to the replacement device. Carlos' test example illustrates this point perfectly. He took specific steps to preserve the original attributes. When the CD/DVD is subsequently mounted and read, those attributes are present and respected. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 14:57, Carl Hartung wrote:
Carlos' test example illustrates this point perfectly. He took specific steps to preserve the original attributes. When the CD/DVD is subsequently mounted and read, those attributes are present and respected.
If you look at the strange filenames I used, that's because each of them tests one of the backup options in k3b. There is a list of options, like "allow ~ in name", etc (that correspond to options in mkisofs), and I wanted to find out what happened. As a matter of fact, I did not activate any of those options, yet the files were correctly copied. I'm not sure why. Interestingly, k3b initially refused to do the burn because all files had zero bytes. I had to add one file with some bytes before it accepted to proceed. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 30/03/2014 14:57, Carl Hartung a écrit :
On Sun, 30 Mar 2014 09:01:11 +0200 jdd jdd wrote:
but how do you test this restore? For data it's pretty easy to restore in a temporary place, but for system?
I'm sure there are more knowledgeable / sophisticated methods available but I just install the replacement drive and partition it (first 'dry run.') Then I restore, chroot in and run the bootloader installation. I use the same method to migrate installations to larger hard drives.
yes, but this needs acces through an opther install or rescu disk, and most rescue disks are short in tools what I asked is did you test your last backup method? locally (as desktop), I never really backup system. I case of failure, I reinstall the newer distribution, but I have a hosted server (two, in fact) and I maintain rsync backups, but restoring is not easy, and tsting the restore even less. In real, the only case I tried to restore a system, I failed :-(
On Sun, 30 Mar 2014 09:09:29 +0200 jdd jdd wrote:
Le 30/03/2014 03:49, Anton Aylward a écrit :
And how did you mount that? Back to the "only root can do that" problem!
AFAIR there is a solution around fuse, but I don't had problem mounting a dvd as user recently
I don't think this is germane.
I answer this question: Back to the "only root can do that" problem! the answer is fuse: http://en.wikipedia.org/wiki/Filesystem_in_Userspace generally speaking, it shouldn't happen in 13.1 jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 16:24, jdd wrote:
Back to the "only root can do that" problem!
cer@Telcontar:~> mount /mnt/dvd cer@Telcontar:~> ls -l /mnt/dvd total 20636 -r--r--r-- 1 root root 13590883 Jul 7 2010 ARCHIVES.gz -r--r--r-- 1 root root 6123701 Jul 7 2010 ChangeLog -r--r--r-- 1 root root 17992 Jul 6 2010 GPLv2.txt -r--r--r-- 1 root root 35147 Jul 6 2010 GPLv3.txt -r--r--r-- 1 root root 79301 Jul 7 2010 INDEX.gz -r--r--r-- 1 root root 1002 Jul 6 2010 README -r--r--r-- 1 root root 2238 Jul 6 2010 SuSEgo.ico ... cer@Telcontar:~> eject /mnt/dvd cer@Telcontar:~> That's using the appropriate entry in fstab, but it also works using the tools in modern desktops. I like manual mounting instead. The files there are owned by root, because that is not a backup media. Another example: cer@Telcontar:~> mount /mnt/dvd cer@Telcontar:~> ls -l /mnt/dvd total 6 dr-xr-xr-x 10 root root 2048 Jan 19 2003 home dr-xr-xr-x 24 root root 4096 Jan 19 2003 rr_moved cer@Telcontar:~> ls -l /mnt/dvd/home/cer/ total 32564 -rw-r--r-- 1 cer_old users 1309 Dec 10 1998 #.bashrc# -rw-r--r-- 1 cer_old users 2046 May 2 2000 #fortune.txt# -rw------- 1 cer_old users 737 Mar 23 2001 #pico01635# -rw------- 1 cer_old users 1260 Aug 14 2002 #pico05457# -rw-r--r-- 1 cer_old users 870 Apr 5 2001 CALLEJERO.url -rw------- 1 cer_old users 2504 Jun 18 2001 DEADJOE ... cer@Telcontar:~> eject /mnt/dvd cer@Telcontar:~> See? no problem. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 03/30/2014 10:50 AM, Carlos E. R. wrote:
That's using the appropriate entry in fstab,
I suspected as much. What was that? /dev/sr0 /mnt/dvd auto rw,user -- No one pretends that democracy is perfect or all-wise. Indeed, it has been said that democracy is the worst form of Government except all those other forms that have been tried from time to time. -- Churchill -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 17:49, Anton Aylward wrote:
On 03/30/2014 10:50 AM, Carlos E. R. wrote:
That's using the appropriate entry in fstab,
I suspected as much. What was that?
/dev/sr0 /mnt/dvd auto rw,user
Close! /dev/dvd /mnt/dvd auto ro,user,noauto 0 0 -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Sun, 30 Mar 2014 16:24:32 +0200 jdd jdd wrote:
Le 30/03/2014 14:57, Carl Hartung a écrit :
On Sun, 30 Mar 2014 09:01:11 +0200 jdd jdd wrote:
but how do you test this restore? For data it's pretty easy to restore in a temporary place, but for system?
I'm sure there are more knowledgeable / sophisticated methods available but I just install the replacement drive and partition it (first 'dry run.') Then I restore, chroot in and run the bootloader installation. I use the same method to migrate installations to larger hard drives.
yes, but this needs acces through an opther install or rescu disk, and most rescue disks are short in tools
what I asked is did you test your last backup method?
Absolutely! It isn't a "backup solution" until it's been tested and proven to work. WRT 'most rescue disks are short on tools', I have not experienced this in recent years. I use three 'rescue' tools on a regular basis: 1) "rescue mode" booted from an openSUSE 12.2 full install DVD (IIRC, the 12.3 GM counterpart has an ACPI related 'wrinkle' at boot that I simply prefer to avoid.) 2) openSUSE 12.3 Live Stick 3) Clonezilla boot CD, primarily used for backing up (cloning) non-Linux partitions.
locally (as desktop), I never really backup system. I case of failure, I reinstall the newer distribution, but I have a hosted server (two, in fact) and I maintain rsync backups, but restoring is not easy, and tsting the restore even less.
In real, the only case I tried to restore a system, I failed :-(
Servers are a completely different realm. In my experience, for the very reasons you've described, unless you have actual physical access to the machine or reliable and experienced hands-on support available, it is usually much more expedient and reliable to recreate the installation from scratch and then restore, from backups, whatever user space, databases and config files are needed to bring the services back online. Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 21:09, Carl Hartung wrote:
WRT 'most rescue disks are short on tools', I have not experienced this in recent years. I use three 'rescue' tools on a regular basis:
Try the "openSUSE rescue live stick", preferably the 13.1 version. It is not installable, doesn't have "office" tools, so it fits in a CD size. In 12.3 the persistent filesystem on stick does not work, but in 13.1 it does, and you can install some extra tools you may need. I find it pretty neat :-)
3) Clonezilla boot CD, primarily used for backing up (cloning) non-Linux partitions.
I recently backed up a full disk (small) via network, using clonezilla. I was using my old laptop, with a pentium 4, and with the default options which include heavy compression, and working over ssh, it was quite slow. I had to setup NFS, and not use clonezilla defaults, so that I could choose the compression method: z3 (lzop) seems to be the optimal one. I found its NFS setup quite dumb: although I had prepared an NFS export for this usage, it instead choose the first exported directory it found on the server, ignoring the specified path. If you tell clonezilla to backup an entire disk, it appears to backup the partition layout using several methods, and it also stores a number of sectors beyond the partition table, the ones where grub is actually stored. This is nice, if it works. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 30/03/2014 21:09, Carl Hartung a écrit :
it is usually much more expedient and reliable to recreate the installation from scratch and then restore, from backups, whatever user space, databases and config files are needed to bring the services back online.
I coudn't because my provider only keep one openSUSE version available for reinstall, and I needed the previous one. I made a complete backup at install timer but couldn't restore it - may be my fault... but it's pretty difficult ti diagnose boot failure remotely :-( jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-03-30 09:01, jdd wrote:
Le 29/03/2014 22:11, Carlos E. R. a écrit :
And it is the case, here, the subject of the thread says, it, backup-restore ;-)
to keep this remark, every body knows any backup is unusefull is one can't test the restore (?).
but how do you test this restore? For data it's pretty easy to restore in a temporary place, but for system?
You can not, unless you really try to restore your system from scratch. A full backup procedure includes grub and partition table, so it means total destruction. Actually, you have to destroy completely your system prior to testing the backup, to verify that it can really recover the system from really scratch. You only do this on expensive systems, if they pay for the test. Or if you are a hobbyist on your own time. Not many more. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Le 29/03/2014 02:28, Anton Aylward a écrit :
OUCH! For some reason everything seemed to be r--r--r-- root.root
rsync options (a)? look also at the option: --rsync-path="rsync --fake-super" my page http://dodin.info/wiki/index.php?n=Doc.Sauvegarde-complete jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Anton Aylward -
Carl Hartung -
Carlos E. R. -
Dylan -
James Knott -
jdd -
Ken Schneider - openSUSE -
Patrick Shanahan