Hi,
GiaThnYgeia wrote:
> Very good information but the word sudo comes up everywhere.
For the purpose of backing up and restoring a whole operating system
with multiple users and partly restrictive permissions: yes.
> If a user does not have sudo rights she/he can back-up files and restore
> th
Very good information but the word sudo comes up everywhere.
If a user does not have sudo rights she/he can back-up files and restore
them as long as s/he has rights to what their backing-up/restoring. So
if you are in a network public environment you may not even have rights
to even your own disk
Hi,
the restore scenario for the xorriso backup would be like this:
- Prepare the storage device to which you want to restore.
This may be as simple as choosing some directory in a filesystem with
enough free space, or as complicated as setting up a new operating
system on a freshly purcha
Hi,
fresh mail from GiaThnYgeia:
> So I decided to run the whole script as sudo or sudo xorriso and it
> seems the problem is solved.
Good to know. You are now supposed to have a copy of the files and
directories of the USB stick.
> Should I attempt to rebuild it to a test disk to see if it rel
Hi,
GiaThnYgeia wrote:
> drwx-- 2 root root 16384 Mar 10 03:21 /media/user/sid/lost+found
If you were not superuser or ran xorriso under sudo, then the ownership
and permissions are a valid reason for being unable to read its content.
I do not generally advise to make backups as superuser. B
I changed the rights 0755 to this lost+ and it got stuck to an other
folder and contents that had only root/owner privileges
So I decided to run the whole script as sudo or sudo xorriso and it
seems the problem is solved.
Should I attempt to rebuild it to a test disk to see if it reliable?
Thoma
On Mon, Mar 13, 2017 at 12:15:00PM +, GiaThnYgeia wrote:
> What is that + at .. root-directory? Mounting point?
> C;/media/user/sid$ ls -alt /media/user/sid
> total 124
> drwxr-x---+ 5 root root 4096 Mar 13 13:52 ..
It indicates the presence of an ACL (file access control list), as
docume
I'll have to learn how to do this trick to (read the fine code of your
email that is that scraps the rest)
Thomas Schmitt:
> ls -ld /media/user/sid/lost+found
I ommitted some of the usual stuff with drwxr-xr-x (the C; is a
joke of course for user@machinename)
What is that + at .. root-dire
Hi,
i quoted man bzip2:
> > As with compression, supplying no filenames causes decompression from
> > standard input to standard output."
GiaThnYgeia wrote:
> ...aka screen dump?
If the standard output of bzip2 is not connected to the standard input
of another process or redirected to a file
On Sun 12 Mar 2017 at 23:50:00 (+), GiaThnYgeia wrote:
> Thomas Schmitt:
> > This is not an answer to my question.
> > Is the reported address a single line
> >
> > /media/user/DebonUSB/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
> > or is it reported as two lines:
> >
Thomas Schmitt:
> Hi,
> i wrote:
>>> bunzip2
> GiaThnYgeia wrote:
>> bunzip2 imagefile | dd of=/dev/sdb
>
> The small but decisive difference is the "<" in my example.
My fault, I thought it was brackets to remind me to enter my own
filename and the second one was missing ;)
> My example gives
Hi,
i wrote:
> > bunzip2 bunzip2 imagefile | dd of=/dev/sdb
The small but decisive difference is the "<" in my example.
My example gives bunzip2 no file path, so that it begins to read from
standard input and writes to standard output. bunzip2's standard
input is redirected from file "imagefile
I am getting a little frustrated as neither dd or xorriso work for me as
I wanted. With the dd and bzip2 combination I got an image really fast
(compared to dd if=.. of=.. ) but when I tried to restore it
dd bs=1M if=/dev/sdb | bzip2 >imagefile
bunzip2 imagefile | dd of=/dev/sdb
it unzipped the i
Hi,
GiaThnYgeia wrote:
> $ xorriso -indev sid1.iso -find / -exec lsdl --
> ...
> drwxr-xr-x1 00 0 Nov 24 11:14 '/'
This explains why the ISO is so small. No files in it.
(The size consists mainly of the traditional 300 KB of padding at the
end of the image.)
> On medi
I am nearly giving up, can't understand what I am doing wrong or what I
should be doing.
Thomas Schmitt:
> Hi,
>
> GiaThnYgeia wrote:
>> Is something wrong?
>> -rw-r--r-- 1 user 458752 Mar 9 00:08 usb_part1.iso
>
> That's much too small for any backup with substance.
> What do you get fr
Hi,
GiaThnYgeia wrote:
> Is something wrong?
> -rw-r--r-- 1 user 458752 Mar 9 00:08 usb_part1.iso
That's much too small for any backup with substance.
What do you get from
xorriso -indev usb_part1.iso -find / -exec lsdl --
Is the USB stick content visible underneath
/mnt/usb-Kingsto
Hi,
GiaThnYgeia wrote:
> $ ls -l
> /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
> total 0
Oops. I should have proposed
ls -ld
so that we see the directory's info rather than the one of its content.
Please retry.
(The USB stick seems not to have been mounted at that m
Thomas Schmitt:
> Hi,
>
> i forgot to adapt my xorriso example from a few days ago:
>
> xorriso \
> -for_backup \
> -outdev usb_part1.iso \
> -map /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1 /
Ok, my drive has grown from 1,7gB to about 2GB since the last try wit
I haven't seen the questions…
On Thu 09 Mar 2017 at 17:37:23 (+0100), Thomas Schmitt wrote:
> GiaThnYgeia wrote:
> > /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
>
> Although it is ugly, i guess it is reproducible whenever you plug in
> that stick and other sticks get oth
Hi,
i forgot to adapt my xorriso example from a few days ago:
xorriso \
-for_backup \
-outdev usb_part1.iso \
-map /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1 /
Note that the last "/" is not a misspelled "\" but the path to the
upcomming ISO's root directory. Th
Hi,
GiaThnYgeia wrote:
> /mnt/usb-Kingston_DataTraveler_3.0_08606E69C773BFC06965007B-0:0-part1
Although it is ugly, i guess it is reproducible whenever you plug in
that stick and other sticks get other reproducible addresses.
(Better test whether the address is indeed the same each time.)
> How
On Wed 08 Mar 2017 at 16:29:00 (+), GiaThnYgeia wrote:
> Hello, this is OP speaking :)
> My use is about 96% backing up the image and only when things fall apart
> will there be a restoring attempt. But what good would saving multiple
> successive images be if none can be ever restored?
This
Hello, this is OP speaking :)
Thomas Schmitt:
> Hi,
>
> David Wright wrote:
>> Forgive me for asking, but have you read the OP?
>
> Yep. It's a daredevil situation. "Damn the torpedos, full speed ahead"
I promise to be more cautious on my next life, maybe a cheetah laying in
the sun all day.
>
Hi,
GiaThnYgeia wrote:
> So each manufacturer may have a different internal system but the output
> is standardized. So we don't really know what goes on in there, right?
Yes. We programmers enjoy the simplified model of an array of consecutive
logical blocks. The physical blocks are a matter of
On 03/07/2017 07:53 PM, GiaThnYgeia wrote:
Once you install a system like debian, does the information
in the hidden part of the disk ever change, of can I just copy the file
system partition as a backup and replace it if it breaks?
AFAIK when using MBR partitioning, the partition table (blocks
On 03/07/2017 12:26 AM, Teemu Likonen wrote:
David Christensen [2017-03-06 21:05:31-08] wrote:
# dd if=/dev/sda | gzip > myimage.img
What's the point of using dd?
gzip myimage.img
Habit -- I use 16 GB SSD or USB flash drives for my system drives, with
10% under-provisioning. 'dd'
Thomas Schmitt:
> Hi,
>
> GiaThnYgeia wrote:
>> 2.1 Block by block, [...] erased data on
>> an empty block can be recovered because they are not zero. Correct?
>
> If not the filesystem overwrote the content of deleted files
> the problem will still be to find the content you are interested in.
Hi,
David Wright wrote:
> Forgive me for asking, but have you read the OP?
Yep. It's a daredevil situation. "Damn the torpedos, full speed ahead"
> I can't see
> the sense of backing up a filesystem to an image file and then, for
> the sake of it, using the image file to overwrite the original
On Tue 07 Mar 2017 at 20:25:30 (+0100), Thomas Schmitt wrote:
> Hi,
>
> i wrote:
> > > It has its use cases. E.g. before you put a Debian installation ISO
> > > onto an USB stick, it can be used to backup the old stick content
>
> David Wright wrote:
> > Why would you now copy the old stick conte
Hi,
i wrote:
> > It has its use cases. E.g. before you put a Debian installation ISO
> > onto an USB stick, it can be used to backup the old stick content
David Wright wrote:
> Why would you now copy the old stick content onto the stick again?
When you no longer need the installation ISO because
Hi,
GiaThnYgeia wrote:
> 1 So an img file does not matter what extension it has,
It's the data content which matters, not the name.
dd or cp don't care about name extensions.
> 2.1 Block by block, [...] erased data on
> an empty block can be recovered because they are not zero. Correct?
If
On Tue 07 Mar 2017 at 18:05:48 (+0100), Thomas Schmitt wrote:
> David Wright wrote:
> > no one has pointed out the recklessness of the
> > action in the first place.
> > Making a backup and then immediately copying it back over the top of
> > the original is an obvious recipe for data-loss.
>
> It
I'd like to thank in advance ALL that responded, I think this is
valuable for an archive of a manual for the nearly illiterate.
Thomas Schmitt:
> GiaThnYgeia wrote:
>>> I used dd if=/dev/sdb of=usbfilename.iso
>>> The resulting image was the full size of the disk.
>
> That's the job of dd: Copyin
Hi,
tomás wrote:
> But yes dd is a dinosaur from olden times where block sizes were a
> thing
It is also about EBCDIC and byte sex. Last century's topics.
Love, 36 bit, and punched cards.
David Wright wrote:
> no one has pointed out the recklessness of the
> action in the first place.
> Making
On Tue 07 Mar 2017 at 10:55:01 (+0200), Teemu Likonen wrote:
> to...@tuxteam.de [2017-03-07 09:35:06+01] wrote:
>
> > dd comes in handy whin you know how much to copy. So this idiom makes
> > sense
> >
> > dd if=/dev/zero of=lotsofnull bs=1024 count=1024 # copy 1M of zeros
>
> That particular t
On Tue 07 Mar 2017 at 00:11:00 (+), GiaThnYgeia wrote:
> I am not very confident I am doing this right and it seems wrong, I
> can't locate any documentation that results into proper options.
> I tried backing up an 8gb USB that has 2 partitions in it, one had 1.7gb
> of data on it.
> I used d
* GiaThnYgeia [2017-03-07 00:11 +]:
> I am not very confident I am doing this right and it seems wrong, I
> can't locate any documentation that results into proper options.
> I tried backing up an 8gb USB that has 2 partitions in it, one had 1.7gb
> of data on it.
> I used dd if=/dev/sdb of=
On Seg, 06 Mar 2017, GiaThnYgeia wrote:
Is there someway one can avoid creating such a large iso for no reason,
when the filesize is a fraction of the whole disk. One way I thought of
was to shrink the partitions to just about 99% full, and leave the blank
part of the disk as not allocated. Wou
On Tue, Mar 07, 2017 at 12:11:00AM +, GiaThnYgeia wrote:
> I am not very confident I am doing this right and it seems wrong, I
> can't locate any documentation that results into proper options.
> I tried backing up an 8gb USB that has 2 partitions in it, one had 1.7gb
> of data on it.
> I used
On Tue, Mar 07, 2017 at 10:26:25AM +0200, Teemu Likonen wrote:
> What's the point of using dd?
>
> gzip myimage.img
>
> I don't know about you but many people seem to think that dd is some
> kind of special tool for reading and writing block device files. But
> after all the devices are just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 07, 2017 at 10:55:01AM +0200, Teemu Likonen wrote:
> to...@tuxteam.de [2017-03-07 09:35:06+01] wrote:
>
> > dd comes in handy whin you know how much to copy. So this idiom makes
> > sense
> >
> > dd if=/dev/zero of=lotsofnull bs=1024 cou
to...@tuxteam.de [2017-03-07 09:35:06+01] wrote:
> dd comes in handy whin you know how much to copy. So this idiom makes
> sense
>
> dd if=/dev/zero of=lotsofnull bs=1024 count=1024 # copy 1M of zeros
That particular thing can be made faster without transferring any data:
$ dd obs=1M count
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 07, 2017 at 10:26:25AM +0200, Teemu Likonen wrote:
> David Christensen [2017-03-06 21:05:31-08] wrote:
>
> > # dd if=/dev/sda | gzip > myimage.img
>
> What's the point of using dd?
>
> gzip myimage.img
>
> I don't know about you
David Christensen [2017-03-06 21:05:31-08] wrote:
> # dd if=/dev/sda | gzip > myimage.img
What's the point of using dd?
gzip myimage.img
I don't know about you but many people seem to think that dd is some
kind of special tool for reading and writing block device files. But
after all th
Hi,
GiaThnYgeia wrote:
> > I used dd if=/dev/sdb of=usbfilename.iso
> > The resulting image was the full size of the disk.
That's the job of dd: Copying block by block.
As David stated, the file usbfilename.iso will not be an ISO 9660 filesystem
but rather a disk image.
David Christensen wrot
On 03/06/2017 09:05 PM, David Christensen wrote:
If you have an SSD, fstrim(8) will discard all unused blocks, regardless
of file system. They should then read as zeros:
https://manpages.debian.org/jessie/util-linux/fstrim.8.en.html
I should qualify that:
If you have an SSD, fstrim(8) wi
On 03/06/2017 04:11 PM, GiaThnYgeia wrote:
I am not very confident I am doing this right and it seems wrong, I
can't locate any documentation that results into proper options.
I tried backing up an 8gb USB that has 2 partitions in it, one had 1.7gb
of data on it.
I used dd if=/dev/sdb of=usbfile
Hi,
On Tue, 07 Mar 2017 00:11:00 +
GiaThnYgeia wrote:
> I am not very confident I am doing this right and it seems wrong, I
> can't locate any documentation that results into proper options.
> I tried backing up an 8gb USB that has 2 partitions in it, one had 1.7gb
> of data on it.
> I used
48 matches
Mail list logo
