Dump/Restore

N

Niatross

I type the following command to backup an active (AKA: "live") file system:

Code: 
dump -C16 -b64 -0uanL -h0 -f /<path>/filename.dump /

I type the following command to restore:

Code: 
restore -ruf /<path>/filename.dump

The Problem:
I always get the following message during the restore:

Code: 
expected next file 102, got 101

Is there any way of getting rid of this message? What is this message anyway?

The restore seems to go fine, but I always get the message (above).
 
It's explained in the restore(8) man page:
Code: 
     expected next file <inumber>, got <inumber>
             A file that was not listed in the directory showed up.  This can
             occur when using a dump created on an active file system.
 
Yes, I'm resurrecting an old thread, I know :)

The hard disk in my Mac Mini started having issues on the /usr partition, so I decided to get everything off it onto a USB connected drive with which I'll ultimately replace the internal drive when I can face dismantling the 2009 Mac Mini.

So, I setup the new drive with GPT scheme partitions and proceeded to dump/restore to the new drive using this command:

root@shadow [/mnt] $ dump -L -C 16 -0af - /dev/ada0p8 | restore -rf -

/dev/ada0p8 has the following attributes:

Code: 
/dev/ada0p8 on /usr (ufs, local, soft-updates)

Journalling has been disabled because of the problem with snapshots and SU+J.

My understanding of the process is that a snapshot is created and then that snapshot is dumped. This being the case, I don't understand why every partition that I've duplicated in this way has a similar message to this:

Code: 
  DUMP: 0.84% done, finished in 7:03 at Sat Feb 25 17:46:22 2017
expected next file 4494340, got 5
  DUMP: 6.46% done, finished in 2:04 at Sat Feb 25 12:52:33 2017

I read the restore() page and noticed the:

expected next file <inumber>, got <inumber>
A file that was not listed in the directory showed up. This can
occur when using a dump created on an active file system.
Click to expand...

explanation of the message, but it makes no sense to me because although it was an active file system, I was dumping a snapshot of it which, by definition, is not active.

Any more ideas as to what is happening?
 
trev said:
My understanding of the process is that a snapshot is created and then that snapshot is dumped.
Click to expand...
Sort off, did you check dump(8) yet? Because if you want safety then I don't understand why you'd use caching at the risk of dump missing files. I know the main concern is only between dumps, but why take that risk?

Anyway, dump makes a snapshot, soft off, but not in the same way file systems such as ZFS do. It simply copies everything on the slice, and that will take its time. That's what you're seeing. This is all mentioned in the manual page.
 
ShelLuser said:
Sort off, did you check dump(8) yet? Because if you want safety then I don't understand why you'd use caching at the risk of dump missing files. I know the main concern is only between dumps, but why take that risk?
Click to expand...

As the system was booted in single user mode almost nothing, was "active", so I didn't see it as a big risk and it certainly improved the speed.

Anyway, dump makes a snapshot, soft off, but not in the same way file systems such as ZFS do. It simply copies everything on the slice, and that will take its time. That's what you're seeing. This is all mentioned in the manual page.
Click to expand...

I'm still not convinced. Every partition (/root, /var, /tmp, /www, /usr, /home) produced a single similar message about a single file.

Now that I'm using the duplicated system on the new hard disk, I have noticed a restoresymtable left behind in every partition's root... maybe that is the file causing the restore message issue as it wasn't in the original dump?
 
trev said:
I'm still not convinced. Every partition (/root, /var, /tmp, /www, /usr, /home) produced a single similar message about a single file.
Click to expand...
No offense intended but do you actually know what the command you used does, or did you simply copy it from an example? Because this should all be very trivial, especially when dealing with backups. And, as mentioned above, this is also all mentioned in the manual pages.

But alas: if you look closely you'll notice that you used 0af - on the command line. -f is used to specify the file to create, but in your command you specified - which stands for standard output; so no file got created but instead the output was send to the console. You then used | to pipe the output to restore. That's why no file got created: instead of creating a file the data got directly sent to the other command which then processed it.

trev said:
I have noticed a restoresymtable left behind in every partition's root... maybe that is the file causing the restore message issue as it wasn't in the original dump?
Click to expand...
restore(8) explains that part. It's only used for incremental restore passes, and can be safely removed.
 
ShelLuser said:
No offense intended but do you actually know what the command you used does, or did you simply copy it from an example? Because this should all be very trivial, especially when dealing with backups. And, as mentioned above, this is also all mentioned in the manual pages.
Click to expand...

I modified an example to do what I wanted after checking the arguments with the man pages. While I'd not used a pipeline from dump to restore before, I have previously used those commands with tape magazines. In this particular instance, however, I was cloning the content of partitions on a Mac Mini to an external USB drive to later replace the internal drive that had started to throw bad sector errors in one partition.

But alas: if you look closely you'll notice that you used 0af - on the command line. -f is used to specify the file to create, but in your command you specified - which stands for standard output; so no file got created but instead the output was send to the console. You then used | to pipe the output to restore. That's why no file got created: instead of creating a file the data got directly sent to the other command which then processed it.
Click to expand...

Yes, I was aware that this was exactly what I was doing. However, it doesn't explain why restore found a file which was not in the directory listing of the dumped snapshot unless I'm misunderstanding something.

restore(8) explains that part. It's only used for incremental restore passes, and can be safely removed.
Click to expand...

Ah, thanks, I'd missed that when I was checking program arguments and I didn't recall ever having seen such a file in the past when I'd done selective interactive tape restores.
 
trev said:
Yes, I was aware that this was exactly what I was doing. However, it doesn't explain why restore found a file which was not in the directory listing of the dumped snapshot unless I'm misunderstanding something.
Click to expand...
No, true, it didn't. The only explanation I have for that would be either the caching or the "live restore". It is possible that one program had to wait for the other a few times which could theoretically cause this. Personally I'm more inclined to 'blame' caching, but only because I never use it with my backups and don't recall coming across these messages.

But in the end I'm not sure about either. You can always use mtree(8) if you need to check that a directory structure got fully copied over.
 
You must log in or register to reply here.
Back
Top