DA system backup issue on FreeBSD 6

[izghitu]

Hi,

I used DA to make full system backups.

Now after a HDD crash I am restoring files but there is a big and important issue.

DA backed up the /etc/shadow file which on FreeBSD 6 does not exist, instead the passwords are stored in master.passwd which was not backed up.

My question is: is there anything I can do to get that master.passwd file or is it lost?

If it's lost then I consider this a DA bug(the fact that it doesn't check for the master.passwd file)

Thanks

 

[nobaloney]

It's most likely lost. Unless you can get it off the old drive.

You can consider it a bug. I'd consider it an unfortunate circumstance based on the fact that no one using DA on FreeBSD has ever tested the backup and reported back to the forums. I've tested it, and most of the files and folders settings posted herein have been as tested by me.

But I use CentOS, RedHat Linux, and RedHat Enterprise Linux, so that's all I've ever tested it on.

Every place I've posted I've always said to test a backup before you have to rely on it.

Don't get me wrong, I'm not making light of your predicament, and I hope everyone who depends on backups will learn from your predicament. Which is why I'm leaving your post under General Technical Discussion rather than moving it to the FreeBSD 6 forum.

Before having DA staff just add the file and the path to the backup system, I'd hope someone will test the backup with the file added and make sure it doesn't break backup on the other systems. Perhaps it'll be necessary to create different backup configurations for different systems.

Jeff

 

[izghitu]

Hi,

Since DirectAdmin costs money, don't you think that the developers and sellers should test it properly before releasing it for a certain OS?

Because of this "untested" thing I have to change all the paswords(150+ users) and then email them all with the new info.

Also when are they going to release an automatic restore capability for full backups?

Thanks

P.S. It's like saying: Please test our code before relying on it; we don't test it ourselves

 

[izghitu]

Another issue is that the backups DID NOT dump the databases. After untarring the database archives I was getting only empty sql dumps: database.sql

Good that the whole mysql binary data directory was archived.

 

[nobaloney]

Since DirectAdmin costs money, don't you think that the developers and sellers should test it properly before releasing it for a certain OS?

Absolutely. My explanation was an explanation. I can only speak for myself, and I certainly wasn't making excuses for anything or anyone.

Because of this "untested" thing I have to change all the paswords(150+ users) and then email them all with the new info.

All nontrivial software has bugs in it. I understand you've found what you consider a bug in DA, and I understand you're upset about it.

We tested DirectAdmin backups almost immediately on switching to DirectAdmin, and that's when I started posting additions to the backup list, many of which were added to the defaults. I was trying to point out that I, NOT DirectAdmin, But I, didn't test for anything except what I run.

Also when are they going to release an automatic restore capability for full backups?

Again, I can't speak for DA staff. I know why I didn't create an automatic restore capability... because there are too many different scenarios to consider, it would be incredibly complex, and it could never be adequately tested.

But that's my opinion. DirectAdmin staff may differ.

Jeff

 

[nobaloney]

Another issue is that the backups DID NOT dump the databases. After untarring the database archives I was getting only empty sql dumps: database.sql

I remember reading somewhere why that may have happened; you might want to search these forums. I know the dumps generally work for us.

Good that the whole mysql binary data directory was archived.

Yes. If I recall correctly, that's why that directory was added.

Jeff

 

[DirectAdmin Support]

Hello,

Thanks for the bug report. I'm amazed nobody had noticed/reported that in the 2 years it's been around. We certainly didn't catch it. As for the passwords, they're probably not totally lost. You can grab the crypted system password from:
/home/username/.shadow
for each user. This will be the same crypted password that was stored in the /etc/master.passwd file.

I've updated the default custom.files here:
http://files.directadmin.com/services/sysbk/mod/custom.files
Place it in:
/usr/local/sysbk/mod/custom.files

Any installs done after this post will have the correct custom.files.

John

 

[pucky]

Hello,

Thanks for the bug report. I'm amazed nobody had noticed/reported that in the 2 years it's been around.

It probably was not reported because anyone restoring data will do it from the primary drive mounted as the secondary back to the primary. In that case you dont need backup to get your files and doing a rsync from old to new will update what you need, when you need it.