Pages

How to check status of software raid on Zentyal 8 (Ubuntu based)

To check the status of my raid on Zentyal File Server (Ubuntu Based) i have done this:

$ sudo cat /proc/mdstat

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
      3906884608 blocks super 1.2 [2/2] [UU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>


After that I done this:

$ sudo mdadm -D /dev/md0


and got this output:

/dev/md0:
           Version : 1.2
     Creation Time : Wed Apr 21 13:38:51 2021
        Raid Level : raid1
        Array Size : 3906884608 (3.64 TiB 4.00 TB)
     Used Dev Size : 3906884608 (3.64 TiB 4.00 TB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Dec 29 15:17:29 2025
             State : clean
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : beta:0  (local to host beta)
              UUID : c48f8912:a38344b0:7af60abb:170fe4d0
            Events : 70848

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1


Which points me to check it even deeper 

$ sudo mdadm -E /dev/sda1


Results:

/dev/sda1:

          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : c48f8912:a38344b0:7af60abb:170fe4d0
           Name : beta:0  (local to host beta)
  Creation Time : Wed Apr 21 13:38:51 2021
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 7813769216 sectors (3.64 TiB 4.00 TB)
     Array Size : 3906884608 KiB (3.64 TiB 4.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=0 sectors
          State : clean
    Device UUID : b3f9004b:c546cc67:1f3de76a:1489687f

Internal Bitmap : 8 sectors from superblock
    Update Time : Mon Dec 29 15:17:29 2025
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : 63d43825 - correct
         Events : 70848

   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)


and the second drive

$ sudo mdadm -E /dev/sdb1


Results:

/dev/sdb1:

          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : c48f8912:a38344b0:7af60abb:170fe4d0
           Name : beta:0  (local to host beta)
  Creation Time : Wed Apr 21 13:38:51 2021
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 7813769216 sectors (3.64 TiB 4.00 TB)
     Array Size : 3906884608 KiB (3.64 TiB 4.00 TB)
    Data Offset : 264192 sectors
   Super Offset : 8 sectors
   Unused Space : before=264112 sectors, after=0 sectors
          State : clean
    Device UUID : 338d1383:62062812:06444fb3:fc1aa8e6

Internal Bitmap : 8 sectors from superblock
    Update Time : Mon Dec 29 15:17:29 2025
  Bad Block Log : 512 entries available at offset 24 sectors
       Checksum : f5ea2412 - correct
         Events : 70848

   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)


Those checks where done because a few years ago after restarting my server - which was running at this time Zentyal v7 - the software raid was broken and I had to reinstall everything and setup from scratch.

In this case - my server run 448 days without restart - after reboot everything was up and running...

Migracja Płatnika z MS Access do SQL Server cz. 3 - Migracja

Kolejna część opisu migracji Płatnika z MS Access do SQL Server.

Najpierw na serwerze SQL Server musimy wykonać następujący skrypt 

sp_configure 'show advanced options', 1;
RECONFIGURE;
GO
sp_configure 'Ad Hoc Distributed Queries', 1;
RECONFIGURE;
GO

który włącza pobieranie danych od zdalnych dostawców OLE DB.

Po zalogowaniu się w systemie przechodzimy w zakładkę Administracja ⟶ Ustawienia bazy danych...













Pojawi nam się następujące okno:












Przechodzimy w zakładkę Baza ⟶ Migracja bazy danych

Po wybraniu tej opcji pojawi się następujace okno, gdzie zazanaczmy Microsoft SQL Server















Wprowadzamy nazwę/IP serwera oraz nazwę dla nowej bazy danych Płatnika.
Ja użyłem nazwy PlatnikSql















Teraz nastąpi pytanie o rodzaj autoryzacji wybieramy: 
Użyj do autoryzacji następującego konta użytkownika bazy SQL Server















Tutaj wprowadzamy nazwę użytkownika i hasło do połączenia z bazą danych















W kolejnym kroku mamy ponownie pytanie o rodzaj autoryzacji, ja podałem login i hasło do połaczenia z bazą danych.





























W kolejnym wybieramy metodę połączenia z bazą danych:
SQLOLEDB lub MSOLEDBSQL - ja musiałem wybrać SQLOLEDEB





























Jesli wszystko przebiegło bez żadnych problemów to powinień pojawić się następujący komunikat















Informujący o tym, że migracja danych przebiegła pomyślnie.

UWAGA!
Podczas migracji danych u mnie pojawił się komunikat o tym, że nie można skopiować danych!

Rozwiązaniem było przeniesienie pliku MDB do katalogu na serwerze, tzn. jeśli bazę access Płatnika mieliście umieszczoną w katalogu np. C:\Platnik\Baza\baza_danych.mdb to plik z bazą należy skopiować na serwer dokładnie do takiego samego katalogu.

Natomiast na forum pomocnikplatnika.pl ktoś napisał, że wgrał plik MDB do katalogu
DATA SQL Server'a - tego nie próbowałem, ale może zadziałać.

Pozostało nam już tylko podłaczyć zmigrowaną bazę do programu Płatnik.


Microsoft Sharepoint 365 - dodawanie kolumny z wersją pliku

Aby dodać kolumnę z numerem wersji pliku/katalogu w Microsoft Sharepoint, trzeba przejść do Wszystkie dokumenty ⟶ Edytuj bieżący widok


























Następnie zaznaczyć: Wersja i/lub Wersja pliku


Od tego momentu w nazwach kolumn pojawią się (w zależności od wyboru) dodatkowe kolumny




























Cheers!