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 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 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

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

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

On 2014-03-30 15:41, James Knott wrote:

Carl Hartung 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. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)

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)

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 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)

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 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)

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

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 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 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)

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

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 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

On 03/29/2014 07:56 AM, Patrick Shanahan wrote:

* Anton Aylward [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

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 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 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 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

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 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)

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 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 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)

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)